This is the mail archive of the
mailing list for the GCC project.
Re: making the new if-converter not mangle IR that is already vectorizer-friendly
- From: Alan Lawrence <alan dot lawrence at arm dot com>
- To: Abe <abe_skolnik at yahoo dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Richard Biener <richard dot guenther at gmail dot com>, Sebastian Pop <sebpop at gmail dot com>
- Date: Tue, 21 Jul 2015 11:19:58 +0100
- Subject: Re: making the new if-converter not mangle IR that is already vectorizer-friendly
- Authentication-results: sourceware.org; auth=none
- References: <55946699 dot 4070803 at yahoo dot com> <559504BE dot 40207 at arm dot com> <5595AB07 dot 7040404 at yahoo dot com> <559657CA dot 4080706 at arm dot com> <559C3CAF dot 9040308 at yahoo dot com> <559CF42B dot 4010308 at arm dot com> <559D5489 dot 1040808 at yahoo dot com> <55AD2DD8 dot 9070000 at arm dot com> <55AD4DF4 dot 5060108 at yahoo dot com>
Ideally, I/we fix the above problem -- and the rest of the regressions in the new if converter --
Ok, what are these regressions? You say you've tested on x86_64 and only
ifcvt-18.c fails (hence your xfail), so how does one find them?
In particular, I remember that "result = condition ? array1[index] : array2[maybe the same index, maybe not]"
is being converted too early IMO. IOW, somewhere in GCC an array dereference is being considered
as either impure, too-expensive, or both. "array[index]" in C [not in C++!: operator overloading]
AFAIK is always pure and is always low-cost whenever the index expression is pure and low-cost.
Well, any array access could introduce an extra fault (unless it's dominated by
another equivalent (read/write) access)...?