On 6/26/23 11:21, Jan Hubicka wrote:
Hi,
playing with testcases for path isolation and const function, I noticed
that we do not seem to even try to isolate out of range array accesses:
int a[3]={0,1,2};
test(int i)
{
if (i > 3)
return test2(a[i]);
return a[i];
}
Hi,
playing with testcases for path isolation and const function, I noticed
that we do not seem to even try to isolate out of range array accesses:
int a[3]={0,1,2};
test(int i)
{
if (i > 3)
return test2(a[i]);
return a[i];
}
Here call to test2 is dead, since a[i] will
> > Also as discussed some time ago, the volatile loads between traps has
> > effect of turning previously pure/const functions into non-const which
> > is somewhat sad, so it is still on my todo list to change it this stage1
> > to something more careful. We discussed internal functions
On 6/22/23 07:42, Jan Hubicka wrote:
On 6/22/23 00:31, Richard Biener wrote:
I think there's a difference in that __builtin_trap () is observable
while __builtin_unreachable () is not and reaching __builtin_unreachable
() invokes undefined behavior while reaching __builtin_trap () does
>
>
> On 6/22/23 00:31, Richard Biener wrote:
> > I think there's a difference in that __builtin_trap () is observable
> > while __builtin_unreachable () is not and reaching __builtin_unreachable
> > () invokes undefined behavior while reaching __builtin_trap () does not.
> >
> > So the
On 6/22/23 00:31, Richard Biener wrote:
I think there's a difference in that __builtin_trap () is observable
while __builtin_unreachable () is not and reaching __builtin_unreachable
() invokes undefined behavior while reaching __builtin_trap () does not.
So the isolation code marking the
On Wed, 21 Jun 2023, Jeff Law wrote:
>
>
> On 6/21/23 00:41, Richard Biener wrote:
> >> I thought during the introduction of erroneous path isolation that we
> >> concluded stores, calls and such had observable side effects that must be
> >> preserved, even when we hit a block that leads to
On 6/21/23 00:41, Richard Biener wrote:
I thought during the introduction of erroneous path isolation that we
concluded stores, calls and such had observable side effects that must be
preserved, even when we hit a block that leads to __builtin_unreachable.
Indeed, I remember we repeatedly
>
> If I manually add a __builtin_unreachable () to the above case
> I see the *(int *)0 = 0; store DSEd. Maybe we should avoid
> removing stores that might trap here? POSIX wise such a trap
> could be a way to jump out of the path leading to unreachable ()
> via siglongjmp ...
I am not sure
On Tue, 20 Jun 2023, Jeff Law wrote:
>
>
> On 6/20/23 00:59, Richard Biener via Gcc-patches wrote:
> > DSE isn't good at identifying program points that end lifetime
> > of variables that are not associated with virtual operands. But
> > at least for those that end basic-blocks we can handle
On 6/20/23 00:59, Richard Biener via Gcc-patches wrote:
DSE isn't good at identifying program points that end lifetime
of variables that are not associated with virtual operands. But
at least for those that end basic-blocks we can handle the simple
case where this ending is in the same
DSE isn't good at identifying program points that end lifetime
of variables that are not associated with virtual operands. But
at least for those that end basic-blocks we can handle the simple
case where this ending is in the same basic-block as the definition
we want to elide. That should catch
12 matches
Mail list logo
