On Wed, Oct 21, 2015 at 7:55 PM, Richard Henderson <r...@redhat.com> wrote: > On 10/21/2015 03:56 AM, Richard Biener wrote: >> >> On Wed, Oct 21, 2015 at 2:45 PM, Richard Biener >> <richard.guent...@gmail.com> wrote: >>> >>> 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. >> >> >> Or maybe we should simply make GIMPLE _always_ adhere to the ABI >> details from the start (gimplification). Note that this does not only >> involve >> PROMOTE_MODE. Note that for what GIMPLE is concerned I'd only >> "lower" passing / returning in registers (whee, and then we have >> things like targetm.calls.split_complex_arg ... not to mention passing >> GIMPLE memory in registers). >> >> Maybe I'm shooting too far here in the attempt to make GIMPLE closer >> to the target (to expose those redundant extensions on GIMPLE) and >> we'll end up with a bigger mess than with not doing this? > > > I'm leary of building this in as early as gimplification, lest we get into > trouble with splitting out bits of the current function for off-loading. > What happens when the cpu and gpu have different promotion rules?
Ah, of course. I tend to forget these issues. Richard. > > r~
