Re: making the new if-converter not mangle IR that is already vectorizer-friendly
[Abe wrote:] Ideally, I/we fix the above problem -- and the rest of the regressions in the new if converter -- [Alan wrote:] OK, what are these regressions? Each of these files` test cases currently fails to be autovectorized: gcc/testsuite/gcc.dg/vect/pr61194.c gcc/testsuite/gcc.dg/vect/vect-mask-load-1.c gcc/testsuite/gcc.dg/vect/vect-mask-loadstore-1.c gcc/testsuite/gcc.target/i386/avx2-gather-6.c gcc/testsuite/gcc.target/i386/avx2-vect-aggressive-1.c gcc/testsuite/gcc.target/i386/avx2-vect-aggressive.c [Alan wrote:] Well, any array access could introduce an extra fault (unless it's dominated by another equivalent (read/write) access)...? I respectfully disagree. Given code such as this: for (unsigned short index = 1; index < 9; ++index) array[index] = index; ... and assuming that "array" is an _array_ variable, i.e. it is _not_ a [re-assignable] pointer, it should be clear IMO to all human readers that this code will not segfault, and if any compiler cannot also correctly arrive at the conclusion "this array access is always good", then that compiler needs to get better at analysis IMO. AFAIK, value range propagation [in the above example, for "index"] has been in GCC for many years... http://www.airs.com/dnovillo/Papers/gcc2005.pdf https://gcc.gnu.org/ml/gcc-patches/2000-07/msg00968.html http://gcc.1065356.n5.nabble.com/Value-range-propagation-pass-in-4-0-1-RC1-or-not-td660293.html [and I`m sure there are many more] Regards, Abe
RE: making the new if-converter not mangle IR that is already vectorizer-friendly
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On > Behalf Of Abe > Sent: Wednesday, July 22, 2015 4:20 AM > > [Abe wrote:] > >> The preceding makes me wonder: has anybody considered adding an > optimization > >> profile for GCC, […] that optimizes for the amount of energy > consumed? > >> I don`t remember reading about anything like that […] > > [Richard wrote:] > > I think there were GCC summit papers/talks about this. > > Thanks, but can you please be more specific? > > After writing the message quotes above as "[Abe wrote:]" > I found 2 or 3 papers about compiling code with an eye > towards energy efficiency, but not a whole hell of a lot, > and I didn`t yet find anything GCC-specific on this topic. In GNU Tools Cauldron 2014 [1] there was a talk titled "Machine Guided Energy Efficient Compilation". You can maybe find more talks and papers by looking at the bibliography of this work. [1] Slides and video are available at https://gcc.gnu.org/wiki/cauldron2014 Best regards, Thomas
RETURN_ADDRESS_POINTER_REGNUM Macro
All: >From the description of the definition of the macro >RETURN_ADDRESS_POINTER_REGNUM , it is derived that this macro is used to Define a register for the above macro that helps in getting the return address from the stack or frame pointer. I could see many of the architectures supported by GCC does not define this macro. Does this impact the performance or correctness of the compiler? On what cases it is applicable to define for the given architecture? Thanks & Regards Ajit
