Re: [PATCH] Fix __builtin_*mul*_overflow* expansion (PR middle-end/90095, take 2)

2019-04-17 Thread Richard Biener
On Tue, 16 Apr 2019, Jakub Jelinek wrote: > On Tue, Apr 16, 2019 at 06:21:25PM +0200, Eric Botcazou wrote: > > > The runtime check assures that at runtime, the upper 32 bits of pseudo 104 > > > must be always 0 (in this case, in some other case could be sign bit > > > copies). > > > > OK, as

[PATCH] Fix __builtin_*mul*_overflow* expansion (PR middle-end/90095, take 2)

2019-04-16 Thread Jakub Jelinek
On Tue, Apr 16, 2019 at 06:21:25PM +0200, Eric Botcazou wrote: > > The runtime check assures that at runtime, the upper 32 bits of pseudo 104 > > must be always 0 (in this case, in some other case could be sign bit > > copies). > > OK, as Richard pointed out, that's not sufficient if we allow...

Re: [PATCH] Fix __builtin_*mul*_overflow* expansion (PR middle-end/90095)

2019-04-16 Thread Eric Botcazou
> The runtime check assures that at runtime, the upper 32 bits of pseudo 104 > must be always 0 (in this case, in some other case could be sign bit > copies). OK, as Richard pointed out, that's not sufficient if we allow... > The question is if it would be valid say for forward propagation to

Re: [PATCH] Fix __builtin_*mul*_overflow* expansion (PR middle-end/90095)

2019-04-16 Thread Jakub Jelinek
On Tue, Apr 16, 2019 at 12:20:16PM +0200, Eric Botcazou wrote: > > If I remember correctly and read the cfgexpand.c comment > > > > /* For a promoted variable, X will not be used directly but wrapped in a > > SUBREG with SUBREG_PROMOTED_VAR_P set, which means that the RTL land > >

Re: [PATCH] Fix __builtin_*mul*_overflow* expansion (PR middle-end/90095)

2019-04-16 Thread Eric Botcazou
> If I remember correctly and read the cfgexpand.c comment > > /* For a promoted variable, X will not be used directly but wrapped in a > SUBREG with SUBREG_PROMOTED_VAR_P set, which means that the RTL land > will assume that its upper bits can be inferred from its lower bits. >

Re: [PATCH] Fix __builtin_*mul*_overflow* expansion (PR middle-end/90095)

2019-04-16 Thread Richard Biener
On Tue, 16 Apr 2019, Jakub Jelinek wrote: > Hi! > > In expand_mul_overflow, we emit (depending on operand ranges etc.) more than > one multiplication to optimize for the common case. One of those is where > we are guaranteed that both operands are either sign or zero extended from > half

[PATCH] Fix __builtin_*mul*_overflow* expansion (PR middle-end/90095)

2019-04-16 Thread Jakub Jelinek
Hi! In expand_mul_overflow, we emit (depending on operand ranges etc.) more than one multiplication to optimize for the common case. One of those is where we are guaranteed that both operands are either sign or zero extended from half precision types to the full precision, we can then use much