[M3devel] m3_load/store using bitfields for everything

[Tony Hosking]

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