[M3devel] further removal of volatile

[Jay K]

I didn't look...but darn..one problem seemingly present here:

/Users/jay/dev2/cm3/caltech-parser/parserlib/klex/AMD64_DARWIN/klex ../src/Calc.l -o CalcLex.i3 -t ../src/Calc.t -ti3 CalcTok.i3


***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x100012fa7 = Output + 0x17 in ../src/NFA.m3
***

"/cm3.amd64/pkg/cit_util/src/generics.tmpl", line 38: quake runtime error: exit 1536: /Users/jay/dev2/cm3/caltech-parser/parserlib/klex/AMD64_DARWIN/klex ../src/Calc.l -o CalcLex.i3 -t ../src/Calc.t -ti3 CalcTok.i3

ugh.

Later..
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 5 Jun 2010 17:46:00 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] further removal of volatile
>
> But what sort of code do you get not using the BIT_FIELD_REF?
>
>
> On 5 Jun 2010, at 16:52, Jay K wrote:
>
>>
>> Tony, Currently we still put volatile on all floating point loads and/or stores.
>> I removed it from all the other types.
>> The main problem I was having is that CopySign in m3core would fail to compile.
>> It is loophoing a float as a struct with bitfields I believe.
>> I didn't look at what the equivalent C tree would be, though that is probably a good idea.
>>
>>
>> With this it seems I don't need the volatile:
>>
>>
>> static void
>> m3_load_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>> bool volatil)
>> {
>> if (o != 0 || TREE_TYPE (v) != src_t)
>> {
>> if (GCC42 || (src_T != dst_T)) <<<
>> {
>> /* failsafe, but inefficient */
>> v = m3_build1 (ADDR_EXPR, t_addr, v);
>> v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>> v = m3_build1 (INDIRECT_REF, src_t,
>> m3_cast (m3_build_pointer_type (src_t), v));
>> }
>> else
>> {
>> v = m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),
>> bitsize_int (o));
>> }
>> }
>> ...
>>
>>
>>
>> static void
>> m3_store_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>> bool volatil)
>> {
>> tree val;
>> if (o != 0 || TREE_TYPE (v) != dst_t)
>> {
>> if (GCC42 || (src_T != dst_T)) <<<<
>> {
>> /* failsafe, but inefficient */
>> v = m3_build1 (ADDR_EXPR, t_addr, v);
>> v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>> v = m3_build1 (INDIRECT_REF, dst_t,
>> m3_cast (m3_build_pointer_type (dst_t), v));
>> }
>> else
>> {
>> v = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),
>> bitsize_int (o));
>> }
>> }..
>>
>> Previously, the code was the equivalent of saying if GCC42 there.
>>
>>
>> Good enough?
>>
>>
>> You know, this bitfield stuff has been a recurring problem.
>>
>> I could probably narrow it down more.
>> Like maybe if the types are the same size or both integers, still go down the old faster path.
>> Though I thought I had tried if they were either float going slow and that didn't work.
>> It might relate to structs as well.
>>
>>
>> However inefficient the non-bitfield ref path is, I can hope/assume it isn't as bad now without volatile.
>> But I could look a bit at the code.
>>
>>
>> - Jay
>>
>