This set of patches reworks the vector extract issues in the V10 patches. If you recall, in V10, you pointed out that for vector extract, the existing code overwrote an input argument, and that is fixed in these patches.
In V10, I added two new constraints (ep and em) to categorize whether a memory is prefixed or not prefixed, and we had some discussion about how to write the predicates. However, yesterday I realized that for the case adding new constraints (vector extract with a variable element number, where the vector is in memory, and we are optimizing the load to just load up the element being extract), what we want is just the address of the vector in a base register. This is because in order access the element where the element number is variable, we eventually will need to do an X-FORM load, with the vector address in one register, and the byte offset in another. Instead of adding new alternatives and new scratch registers, I could just simplify the code and use the 'Q' constraint that says use a single register as the address. The register allocator will do the necessary work to load up the address during register allocation. I did notice that the documentation for 'Q' was wrong, so one of the patches updates the documentation. In addition, after committing the first 3 patches from V10 that added PADDI and PLI support for -mcpu=future, Segher asked me to do a patch to rename two of the macros. That patch is now checked in, and some of these patches include changes due to the macro renaming. After the vector extract patch rework, I included the remaining patch to the compiler (make -mpcrel default on Linux 64-bit for -mcpu=future). I included the tests after doing the -mpcrel default changes. In addition to the tests in V10, I added some new tests for the vector extract code. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
