Diego Novillo wrote:
> Eric Botcazou wrote on 06/21/06 10:05:
>
>> It seems to me that the volatility should be accounted for in the
>> VALUE_HANDLE
>> itself only, not in (de)references to it.
>>
> As Richard and Andrew pointed out, the bug is that we try to compute the
> value number of a stat
Eric Botcazou wrote on 06/21/06 10:05:
> It seems to me that the volatility should be accounted for in the
> VALUE_HANDLE
> itself only, not in (de)references to it.
>
As Richard and Andrew pointed out, the bug is that we try to compute the
value number of a statement with volatile references i
> What do you mean by "in the VALUE_HANDLE itself"?
Returning a different VALUE_HANDLE for each instance of a volatile expression.
> I think we should not bother value-numbering volatile mem-accesses at all.
I guess that would be even better. :-)
Thanks for the quick feedback.
--
Eric Botcazo
On Jun 21, 2006, at 7:05 AM, Eric Botcazou wrote:
Hi,
We're experiencing a memory explosion during PRE on several ACATS
tests with
mainline (+1 local patch, but it's very likely the same issue as PR
27937).
The VN should not have been created and stmt_ann (stmt)-
>has_volatile_ops shoul
On 6/21/06, Eric Botcazou <[EMAIL PROTECTED]> wrote:
Hi,
We're experiencing a memory explosion during PRE on several ACATS tests with
mainline (+1 local patch, but it's very likely the same issue as PR 27937).
Excerpt from .067t.pre:
Created value VH.26 for (struct cd5012i__genproc__cell *vola
Hi,
We're experiencing a memory explosion during PRE on several ACATS tests with
mainline (+1 local patch, but it's very likely the same issue as PR 27937).
Excerpt from .067t.pre:
Created value VH.26 for (struct cd5012i__genproc__cell *volatile & {ref-all})
VH.25
Created value VH.33 for *VH.2
