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?
r~
