[M3devel] m3_load/store using bitfields for everything

[Tony Hosking]

I'm working on it.

On 20 May 2009, at 12:20, Jay wrote:

>
> 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
>>