[M3devel] deeper meaning of in_memory?

[Antony Hosking]

Good question.  But if you are good about making the structs anonymous and taking their address then TBAA in C should not give you problems.

On Sep 28, 2012, at 3:31 PM, Jay K <jay.krell at cornell.edu> wrote:

> > structs volatile
> 
> Mainly paranoia.
> But I do wonder if the breakage I saw in gcc's "sra" optimization pass (structure replaced by aggregate) by feeding it trees can be reproduced from C. I should look into that...
> 
> 
>  - Jay
> 
> Subject: Re: [M3devel] deeper meaning of in_memory?
> From: hosking at cs.purdue.edu
> Date: Fri, 28 Sep 2012 10:11:49 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> in_memory does not mean volatile.  It is simply a sign that its address is needed.
> So, yes, taking its address is good enough.
> An example of a local in memory is something passed by VAR.
> 
> So, NOT VOLATILE.
> 
> Why do structs need to be C volatile?
> 
> On Sep 27, 2012, at 10:57 PM, Jay K <jay.krell at cornell.edu> wrote:
> 
> In M3CG, what is the deeper meaning of in_memory?
> I know it means -- "put the thing in memory".
> But why and exactly what?
> Presumably it can also be in a register, just that the in-memory value must be kept up to date.
> Like, stores should be volatile, but reads don't have to be?
> Does it mean the value will be used in an exception/finally handler?
> Maybe reads do need to be volatile? Maybe it is accessed by another thread w/o a lock?
> 
> 
> If I take the address of something, is that good enough?
> 
> 
> I should just look where m3front uses it, I know.
> For now I'll probably take it to mean "volatile".
> I already mark all structs as volatile. But I don't make everything volatile (like how m3cc long did).
> 
> 
> Thanks,
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120928/ff3eedf4/attachment-0001.html>