Hi Jakub,
> On Thu, Oct 08, 2020 at 11:37:24AM +, Wilco Dijkstra via Gcc-patches
> wrote:
>> Which optimizations does it enable that aren't possible if the value is
>> defined?
>
> See bugzilla. Note other compilers heavily optimize on those builtins
> undefined at value zero.
You mean
On Thu, Oct 08, 2020 at 11:37:24AM +, Wilco Dijkstra via Gcc-patches wrote:
> Which optimizations does it enable that aren't possible if the value is
> defined?
See bugzilla. Note other compilers heavily optimize on those builtins
undefined at value zero.
> > We just should make sure that
Hi Jakub,
> Having it undefined allows optimizations, and has been that way for years.
Which optimizations does it enable that aren't possible if the value is defined?
> We just should make sure that we optimize code like x ? __builtin_c[lt]z (x)
> : 32;
> etc. properly (and I believe we do).
Btw for PowerPC is 0..32:
https://www.ibm.com/support/knowledgecenter/ssw_aix_72/assembler/idalangref_cntlzw_instrs.html
Wilco
On Thu, Oct 08, 2020 at 11:22:34AM +, Wilco Dijkstra wrote:
> >> I think a better way forward would be to make the builtin_clz/ctz more
> >> defined.
> >> Having undefined values is a source of unnecessary bugs given practically
> >> all
> >> modern targets return the number of bits for the
Hi Jakub,
>> I think a better way forward would be to make the builtin_clz/ctz more
>> defined.
>> Having undefined values is a source of unnecessary bugs given practically all
>> modern targets return the number of bits for the zero input - it is
>> relatively
>> easy to ensure this on the few
On Thu, Oct 08, 2020 at 11:04:01AM +, Wilco Dijkstra wrote:
> > Perhaps another way out of this would be document and enforce that
> > __builtin_c[lt]z{,l,ll} etc calls are undefined at zero, but C[TL]Z ifn
> > calls are defined there based on *_DEFINED_VALUE_AT_ZERO (*) == 2, and then
> > we
Hi Jakub,
> Perhaps another way out of this would be document and enforce that
> __builtin_c[lt]z{,l,ll} etc calls are undefined at zero, but C[TL]Z ifn
> calls are defined there based on *_DEFINED_VALUE_AT_ZERO (*) == 2, and then
> we would need to make sure that e.g. in
Hi,
> I am quoting my analysis from the PR. Could an aarch64 expert
> pontificate here?
>
> This test is checking the final assembly for a specific sequence. I
> don't speak aarch64 assembly, but the IL is different coming out of evrp.
The code currently generated is incorrect - you really
On Thu, Oct 08, 2020 at 12:22:11PM +0200, Jakub Jelinek via Gcc-patches wrote:
> We have several enhancement reports in bugzilla from Gabriel Ravier on this
> topic I think.
See e.g. PR94801, PR94793, PR95863 on the topic.
Jakub
On Thu, Oct 08, 2020 at 11:58:21AM +0200, Aldy Hernandez via Gcc-patches wrote:
> I am quoting my analysis from the PR. Could an aarch64 expert pontificate
> here?
>
> This test is checking the final assembly for a specific sequence. I don't
> speak aarch64 assembly, but the IL is different
I am quoting my analysis from the PR. Could an aarch64 expert
pontificate here?
This test is checking the final assembly for a specific sequence. I
don't speak aarch64 assembly, but the IL is different coming out of evrp.
The first culprit is this difference in the mergephi1 dump:
_9 =
12 matches
Mail list logo
