On Tue, Oct 20, 2015 at 10:03 PM, Kugan <kugan.vivekanandara...@linaro.org> wrote: > > > On 07/09/15 12:53, Kugan wrote: >> >> This a new version of the patch posted in >> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00226.html. I have done >> more testing and spitted the patch to make it more easier to review. >> There are still couple of issues to be addressed and I am working on them. >> >> 1. AARCH64 bootstrap now fails with the commit >> 94f92c36a83d66a893c3bc6f00a038ba3dbe2a6f. simplify-rtx.c is mis-compiled >> in stage2 and fwprop.c is failing. It looks to me that there is a latent >> issue which gets exposed my patch. I can also reproduce this in x86_64 >> if I use the same PROMOTE_MODE which is used in aarch64 port. For the >> time being, I am using patch >> 0006-temporary-workaround-for-bootstrap-failure-due-to-co.patch as a >> workaround. This meeds to be fixed before the patches are ready to be >> committed. >> >> 2. vector-compare-1.c from c-c++-common/torture fails to assemble with >> -O3 -g Error: unaligned opcodes detected in executable segment. It works >> fine if I remove the -g. I am looking into it and needs to be fixed as well. > > Hi Richard, > > Now that stage 1 is going to close, I would like to get these patches > accepted for stage1. I will try my best to address your review comments > ASAP.
Ok, can you make the whole patch series available so I can poke at the implementation a bit? Please state the revision it was rebased on (or point me to a git/svn branch the work resides on). > * Issue 1 above (AARCH64 bootstrap now fails with the commit) is no > longer present as it is fixed in trunk. Patch-6 is no longer needed. > > * Issue 2 is also reported as known issue > > * Promotion of PARM_DECLs and RESULT_DECLs in IPA pass and patterns in > match.pd for SEXT_EXPR, I would like to propose them as a follow up > patch once this is accepted. I thought more about this and don't think it can be made work without a lot of hassle. Instead to get rid of the remaining "badly" typed registers in the function we can key different type requirements on a pass property (PROP_promoted_regs), thus simply change the expectation of the types of function parameters / results according to their promotion. The promotion pass would set PROP_promoted_regs then. I will look over the patch(es) this week but as said I'd like to play with some code examples myself and thus like to have the current patchset in a more easily accessible form (and sure to apply to some rev.). Thanks, Richard. > * I am happy to turn this pass off by default till IPA and match.pd > changes are accepted. I can do regular testing to make sure that this > pass works properly till we enable it by default. > > > Please let me know what you think, > > Thanks, > Kugan
