[M3devel] m3_load/store using bitfields for everything

[Jay]

This is with no optimization at all.
 
I haven't tried replacing it with volatize.
The problem on MIPS64_OPENBSD was the notion that bitfields fit in a register so any offset beyond a register was thrown out, or something.
 
I do think a "component ref" would be appropriate, but don't know if it is a lot of work, to get the typeinfo through.
 
 - Jay

----------------------------------------
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Subject: Re: m3_load/store using bitfields for everything
> Date: Wed, 20 May 2009 10:23:33 +1000
>
> What optimization level are you using?
>
> I think what it comes down to is figuring out why the backend
> eliminates those globals and setting them up so it doesn't. There is
> usually some gcc incantation that will do the trick, but it often
> involves deep reading of the gcc source code.
>
> I am in the middle of that for the SOLgnu optimization failures (that
> we did not used to see until I upgraded to gcc 4.3.0 last year. I
> wonder if the TREE_THIS_VOLATILE bit is no longer sufficient. Can you
> see what happens if you replace that with m3_volatilize_decl instead?
> This was needed for the variables used in functions calling setjmp and
> may be necessary here too.
>
> On 20 May 2009, at 09:14, Jay wrote:
>
>> m3_load/store using bitfields for everything caused module-global
>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked
>> around that by declaring that the module-globals are at least of
>> size 2 * biggest_alignment.
>>
>> It caused module-global references to disappear on ARM_DARWIN as well.
>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't
>> occur and PutChar eventually failed an array bounds check.
>>
>> Is this just too fragile and the failsafe form should always be used?
>>
>> Or, it fails spectacularly consistently enough that it must also be
>> working consistently enough and leave it?
>>
>> Would "component ref" (ie: struct) and declaring more type
>> information about module segments be a good compromise maybe?
>> Probably.
>>
>> - Jay
>