Hi Ho!
On Fri, 2009-03-27 at 13:49 +0100, Paolo Bonzini wrote:
> Eus wrote:
> > Hi Ho!
> >
> > On Fri, 2009-03-06 at 15:29 +0100, Paolo Bonzini wrote:
> >>> So while trapping variants can certainly be introduced it looks like
> >>> this task may be more difficult.
> >> I don't think you need to i
Eus wrote:
> Hi Ho!
>
> On Fri, 2009-03-06 at 15:29 +0100, Paolo Bonzini wrote:
>>> So while trapping variants can certainly be introduced it looks like
>>> this task may be more difficult.
>> I don't think you need to introduce trapping tree codes. You can
>> introduce them directly in the front
Hi Ho!
On Fri, 2009-03-06 at 15:29 +0100, Paolo Bonzini wrote:
> > So while trapping variants can certainly be introduced it looks like
> > this task may be more difficult.
>
> I don't think you need to introduce trapping tree codes. You can
> introduce them directly in the front-end as
>
>
On Fri, 6 Mar 2009, Paolo Bonzini wrote:
> Joseph S. Myers wrote:
> > On Fri, 6 Mar 2009, Geert Bosch wrote:
> >
> >>> this task may be more difficult. So lowering them early during
> >>> gimplification looks like a more reasonable plan IMHO.
> >> Right, that was my intention. Still, I'll need t
On Fri, 6 Mar 2009, Geert Bosch wrote:
>
> On Mar 6, 2009, at 12:22, Joseph S. Myers wrote:
> > If you add new trapping codes to GENERIC I'd recommend *not* making fold()
> > handle them. I don't think much folding is safe for the trapping codes
> > when you want to avoid either removing or intr
On Mar 6, 2009, at 12:22, Joseph S. Myers wrote:
If you add new trapping codes to GENERIC I'd recommend *not* making
fold()
handle them. I don't think much folding is safe for the trapping
codes
when you want to avoid either removing or introducing traps. Either
lower
the codes in gimpli
Ian Lance Taylor wrote:
Richard Earnshaw writes:
On Fri, 2009-03-06 at 16:09 +0100, Paolo Bonzini wrote:
If this does not work, on ARM you can also hope for something like this:
ADDR0, R1, R2
XORS R0, R2, R3
XORSMI R1, R2, R3
SWIMI #trap
On ARM you can just check
Richard Earnshaw writes:
> On Fri, 2009-03-06 at 16:09 +0100, Paolo Bonzini wrote:
>> If this does not work, on ARM you can also hope for something like this:
>>
>> ADDR0, R1, R2
>> XORS R0, R2, R3
>> XORSMI R1, R2, R3
>> SWIMI #trap
>
> On ARM you can just check for o
>> If this does not work, on ARM you can also hope for something like this:
>>
>> ADDR0, R1, R2
>> XORS R0, R2, R3
>> XORSMI R1, R2, R3
>> SWIMI #trap
>
> On ARM you can just check for overflow directly...
>
> ADDSR0, R1, R2
> SWIVS #trap
Of course,
On Fri, 2009-03-06 at 16:09 +0100, Paolo Bonzini wrote:
> If this does not work, on ARM you can also hope for something like this:
>
> ADDR0, R1, R2
> XORS R0, R2, R3
> XORSMI R1, R2, R3
> SWIMI #trap
On ARM you can just check for overflow directly...
ADDSR
Joseph S. Myers wrote:
> On Fri, 6 Mar 2009, Geert Bosch wrote:
>
>>> this task may be more difficult. So lowering them early during
>>> gimplification looks like a more reasonable plan IMHO.
>> Right, that was my intention. Still, I'll need to add code to
>> handle the new tree codes in fold(),
On Fri, 6 Mar 2009, Paolo Bonzini wrote:
> Joseph S. Myers wrote:
> > On Fri, 6 Mar 2009, Paolo Bonzini wrote:
> >
> >> I don't think you need to introduce trapping tree codes. You can
> >> introduce them directly in the front-end as
> >
> > Multiple front ends want the same thing. This is why
Joseph S. Myers wrote:
> On Fri, 6 Mar 2009, Paolo Bonzini wrote:
>
>> I don't think you need to introduce trapping tree codes. You can
>> introduce them directly in the front-end as
>
> Multiple front ends want the same thing. This is why it would be better
> to introduce the codes in GENERIC
On Fri, 6 Mar 2009, Geert Bosch wrote:
> In any case, while I'd really like to move the checked signed
> integer overflow from Gigi (GNAT-to-GNU tree translator) to
> the language independent part of GCC, I want to have the absolute
> minimum amount of changes that is necessary to achieve this goa
On Fri, 6 Mar 2009, Geert Bosch wrote:
> > this task may be more difficult. So lowering them early during
> > gimplification looks like a more reasonable plan IMHO.
>
> Right, that was my intention. Still, I'll need to add code to
> handle the new tree codes in fold(), right?
If you add new tra
On Fri, 6 Mar 2009, Paolo Bonzini wrote:
> I don't think you need to introduce trapping tree codes. You can
> introduce them directly in the front-end as
Multiple front ends want the same thing. This is why it would be better
to introduce the codes in GENERIC and have the language-independent
On Fri, 6 Mar 2009, Richard Guenther wrote:
> Well, I was thinking about detecting the pattern on the tree level instead.
>
> s_6 = x.0_2 + y.1_4;
> D.1597_7 = s_6 ^ x_1(D);
> D.1598_8 = s_6 ^ y_3(D);
> D.1599_9 = D.1597_7 & D.1598_8;
> if (D.1599_9 < 0)
> goto ;
> else
> goto
On Mar 6, 2009, at 04:11, Richard Guenther wrote:
I didn't spend too much time thinking about the trapping variants
(well, I believe it isn't that important ;)). But in general we would
have to expand the non-NV variants via the trapping expanders
if flag_trapv was true (so yeah, combining TUs
On Mar 6, 2009, at 09:15, Joseph S. Myers wrote:
It looks like only alpha and pa presently have insn patterns such as
addvsi3 that would be used by the present -ftrapv code, but I expect
several other processors also have instructions that would help in
overflow-checking code. (For example, Pow
On Fri, Mar 6, 2009 at 4:09 PM, Paolo Bonzini wrote:
> Richard Guenther wrote:
>> On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini wrote:
So while trapping variants can certainly be introduced it looks like
this task may be more difficult.
>>> I don't think you need to introduce trapping t
Richard Guenther writes:
> I agree. Btw, for the addition case we generate
>
> leal(%rsi,%rdi), %eax
> xorl%eax, %esi
> xorl%eax, %edi
> testl %edi, %esi
> jns .L2
> .value 0x0b0f
> .L2:
> rep
> ret
>
> wh
Richard Guenther wrote:
> On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini wrote:
>>> So while trapping variants can certainly be introduced it looks like
>>> this task may be more difficult.
>> I don't think you need to introduce trapping tree codes. You can
>> introduce them directly in the front-
On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini wrote:
>
>> So while trapping variants can certainly be introduced it looks like
>> this task may be more difficult.
>
> I don't think you need to introduce trapping tree codes. You can
> introduce them directly in the front-end as
>
> s = x +nv y
> So while trapping variants can certainly be introduced it looks like
> this task may be more difficult.
I don't think you need to introduce trapping tree codes. You can
introduce them directly in the front-end as
s = x +nv y
(((s ^ x) & (s ^ y)) < 0) ? trap () : s
d = x -nv y
(((
On Fri, 6 Mar 2009, Richard Guenther wrote:
> Ok, I didn't think of generating optimal code for the overflow checks,
> but it should be reasonably possible to if-convert the explicit
> overflow checks back to builtins that can be specially expanded
> (that would also help explicit overflow checks
On Fri, 6 Mar 2009, Joseph S. Myers wrote:
> On Fri, 6 Mar 2009, Richard Guenther wrote:
>
> > There is of course the problem that we have to be careful not to
> > introduce new traps via folding, a problem that doesn't exist with
> > the no-overflow variants (I can simply drop to the wrapping va
On Fri, 6 Mar 2009, Richard Guenther wrote:
> There is of course the problem that we have to be careful not to
> introduce new traps via folding, a problem that doesn't exist with
> the no-overflow variants (I can simply drop to the wrapping variants).
> With for example (a -/v 10) +/v 10 would y
On Thu, 5 Mar 2009, Geert Bosch wrote:
> Hi Richard,
>
> Great to see that you're addressing this issue. If I understand correctly,
> for RTL all operations are always wrapping, right?
That's true (we don't have signedness information there) and I don't
plan to change that.
> I have been consid
Hi Richard,
Great to see that you're addressing this issue. If I understand
correctly,
for RTL all operations are always wrapping, right?
I have been considering adding "V" variants for operations that trap on
overflow. The main reason I have not (yet) pursued this, is the daunting
task of te
On Sat, 28 Feb 2009, Joseph S. Myers wrote:
> On Fri, 27 Feb 2009, Diego Novillo wrote:
>
> > We will be reading IL containing both overflow and non-overflow
> > operations. We should define the combination rules for them.
>
> The rules are simple:
>
> * No transformation (of arithmetic operat
On Fri, 27 Feb 2009, Diego Novillo wrote:
> On Thu, Feb 26, 2009 at 06:05, Richard Guenther wrote:
>
>
> > There shall be no construct in the GIMPLE IL that invokes
> > undefined behavior.
>
> Excellent! Thanks for starting this branch.
>
> > Thus, from now on integer overflow is defined a
On Fri, 27 Feb 2009, Diego Novillo wrote:
> We will be reading IL containing both overflow and non-overflow
> operations. We should define the combination rules for them.
The rules are simple:
* No transformation (of arithmetic operations, which is what we are
discussing here) may change defin
On Thu, Feb 26, 2009 at 06:05, Richard Guenther wrote:
> There shall be no construct in the GIMPLE IL that invokes
> undefined behavior.
Excellent! Thanks for starting this branch.
> Thus, from now on integer overflow is defined and will wrap with
> the usual twos-complement semantics. Thu
Jay Foad writes:
>From an optimisation pass's point of view, what's the difference between:
>
> 1. a PLUS expression that gives an undefined result on overflow, and
> 2. a PLUS expression with a guarantee that the result won't overflow.
>
> I can't see how they will be handled any differently in
On Fri, 27 Feb 2009, Jay Foad wrote:
> > To support languages that have undefined semantics on overflowing
> > operations the middle-end gets new unary and binary operators
> > that implicitly encode value-range information about their operands
> > noting that the operation does not overflow. The
> To support languages that have undefined semantics on overflowing
> operations the middle-end gets new unary and binary operators
> that implicitly encode value-range information about their operands
> noting that the operation does not overflow. These does-not-overflow
> operators transform the
On Fri, 27 Feb 2009, Zdenek Dvorak wrote:
> Hi,
>
> > > introducing new codes seems like a bad idea to me. There are many
> > > places that do not care about the distinction between PLUS_EXPR and
> > > PLUSV_EXPR, and handling both cases will complicate the code (see eg.
> > > the problems cause
Hi,
> > I obviously thought about this. The issue with using a flag is
> > that there is no convenient place to stick it and that it makes
> > the distinction between the two variants less visible. Consider
> > the folding routines that take split trees for a start.
> >
> > IMHO using new tree-
Hi,
> > introducing new codes seems like a bad idea to me. There are many
> > places that do not care about the distinction between PLUS_EXPR and
> > PLUSV_EXPR, and handling both cases will complicate the code (see eg.
> > the problems caused by introducing POINTER_PLUS_EXPR vs PLUS_EXPR
> > dis
On Fri, 27 Feb 2009, Dave Korn wrote:
> Richard Guenther wrote:
>
> > It's definitely safer. Still we have to carefully modify existing
> > code to deal with the new tree codes as most of it carelessly
> > transitiones old codes to new trees. For example re-associating
> > (a +/nv b) + c to a +
Richard Guenther wrote:
> It's definitely safer. Still we have to carefully modify existing
> code to deal with the new tree codes as most of it carelessly
> transitiones old codes to new trees. For example re-associating
> (a +/nv b) + c to a +/nv (b + c) is wrong.
Yes, of course we have to
On Fri, 27 Feb 2009, Dave Korn wrote:
> Richard Guenther wrote:
> > On Fri, 27 Feb 2009, Zdenek Dvorak wrote:
>
> >> introducing new codes seems like a bad idea to me. There are many
> >> places that do not care about the distinction between PLUS_EXPR and
> >> PLUSV_EXPR, and handling both cases
Richard Guenther wrote:
> On Fri, 27 Feb 2009, Zdenek Dvorak wrote:
>> introducing new codes seems like a bad idea to me. There are many
>> places that do not care about the distinction between PLUS_EXPR and
>> PLUSV_EXPR, and handling both cases will complicate the code (see eg.
>> the problems
On Fri, 27 Feb 2009, Zdenek Dvorak wrote:
> Hi,
>
> in general, I like this proposal a lot. However,
>
> > As a start there will be no-overflow variants of NEGATE_EXPR,
> > PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR.
> >
> > The sizetypes will simply be operated on in no-overflow v
Hi,
in general, I like this proposal a lot. However,
> As a start there will be no-overflow variants of NEGATE_EXPR,
> PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR.
>
> The sizetypes will simply be operated on in no-overflow variants
> by default (by size_binop and friends).
>
> Nami
Richard Guenther wrote:
> As a start there will be no-overflow variants of NEGATE_EXPR,
> PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR.
> Naming suggestions welcome, at the moment I consider NEGATEV_EXPR
> (thus appending V to the first part).
Wow, an actual /invitation/ to bikeshed!
On Thu, 26 Feb 2009, Joseph S. Myers wrote:
> On Thu, 26 Feb 2009, Richard Guenther wrote:
>
> > As a start there will be no-overflow variants of NEGATE_EXPR,
> > PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR.
>
> So you would have both wrapping and no-overflow versions of these codes
On Thu, 26 Feb 2009, Richard Guenther wrote:
> As a start there will be no-overflow variants of NEGATE_EXPR,
> PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR.
So you would have both wrapping and no-overflow versions of these codes
(with it of course always being valid for a transformatio
On Thu, 26 Feb 2009, Manuel López-Ibáñez wrote:
> 2009/2/26 Richard Guenther :
> >
> > There shall be no construct in the GIMPLE IL that invokes
> > undefined behavior.
>
> What about uninitialized variables?
That's unrelated and something I do not care about.
Richard.
2009/2/26 Richard Guenther :
>
> There shall be no construct in the GIMPLE IL that invokes
> undefined behavior.
What about uninitialized variables?
Cheers,
Manuel.
There have been numerous issues in the past with respect to the
undefinedness of signed overflow in our IL, with the non-semantics
of sizetype and friends and with the pessimization of using
unsigned arithmetic vs. signed arithmetic in loop optimizations.
The goal of the no-undefined-overflow bra
51 matches
Mail list logo
