On 28/04/15 10:54, Kyrill Tkachov wrote:
On 27/04/15 21:13, Jeff Law wrote:
On 04/21/2015 11:33 AM, Kyrill Tkachov wrote:
On 21/04/15 15:09, Jeff Law wrote:
On 04/21/2015 02:30 AM, Kyrill Tkachov wrote:
From reading config/stormy16/stormy-abi it seems to me that we don't
pass arguments partially in stormy16, so this code would never be called
there. That leaves pa as the potential problematic target.
I don't suppose there's an easy way to test on pa? My checkout of
binutils
doesn't seem to include a sim target for it.
No simulator, no machines in the testfarm, the box I had access to via
parisc-linux.org seems dead and my ancient PA overheats well before a
bootstrap could complete. I often regret knowing about the backwards
way many things were done on the PA because it makes me think about
cases that only matter on dead architectures.
So what should be the action plan here? I can't add an assert on
positive result as a negative result is valid.
We want to catch the case where this would cause trouble on
pa, or change the patch until we're confident that it's fine
for pa.
That being said, reading the documentation of STACK_GROWS_UPWARD
and ARGS_GROW_DOWNWARD I'm having a hard time visualising a case
where this would cause trouble on pa.
Is the problem that in the function:
+/* Add SIZE to X and check whether it's greater than Y.
+ If it is, return the constant amount by which it's greater or smaller.
+ If the two are not statically comparable (for example, X and Y contain
+ different registers) return -1. This is used in expand_push_insn to
+ figure out if reading SIZE bytes from location X will end up reading
from
+ location Y. */
+static int
+memory_load_overlap (rtx x, rtx y, HOST_WIDE_INT size)
+{
+ rtx tmp = plus_constant (Pmode, x, size);
+ rtx sub = simplify_gen_binary (MINUS, Pmode, tmp, y);
+
+ if (!CONST_INT_P (sub))
+ return -1;
+
+ return INTVAL (sub);
+}
for ARGS_GROW_DOWNWARD we would be reading 'backwards' from x,
so the function should something like the following?
So I had to go back and compile some simple examples.
References to outgoing arguments will be SP relative. References to the
incoming arguments will be ARGP relative. And that brings me to the
another issue. Isn't X in this context the incoming argument slot and
the destination an outgoing argument slot?
If so, the approach of memory_load_overlap simply won't work on a target
with calling conventions like the PA. And you might really want to
consider punting for these kind of calling conventions
Ok, thanks for the guidance.
How about this? This patch disables sibcall optimisation when
encountering a partial argument when ARGS_GROW_DOWNWARD &&
!STACK_GROWS_DOWNWARD.
Hopefully this shouldn't harm codegen on parisc if, as you say, it's rare to
have
partial arguments anyway on PA due to the large number of argument regs.
I tested this on arm and bootstrapped on x86_64.
I am now going through the process of getting access to a Debian PA machine to
give it a test there (thanks Dave!)
Ok if testing comes clean?
Hi Jeff,
So I got access to an hppa machine.
But as mentioned here https://gcc.gnu.org/ml/gcc/2015-04/msg00364.html
I don't think I can bootstrap and run a 64-bit pa testsuite.
I've verified that the compiler builds, but is there anything more I can
do in testing this patch?
The latest version is at
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01713.html
and disables sibcall optimisation on a target like pa when a partial argument
is encountered.
Thanks,
Kyrill
Thanks,
Kyrill
2015-04-28 Kyrylo Tkachov <kyrylo.tkac...@arm.com>
PR target/65358
* calls.c (expand_call): Cancel sibcall optimisation when encountering
partial argument on targets with ARGS_GROW_DOWNWARD and
!STACK_GROWS_DOWNWARD.
* expr.c (memory_load_overlap): New function.
(emit_push_insn): When pushing partial args to the stack would
clobber the register part load the overlapping part into a pseudo
and put it into the hard reg after pushing.
2015-04-28 Honggyu Kim <hong.gyu....@lge.com>
PR target/65358
* gcc.dg/pr65358.c: New test.
If you hadn't already done the work, I'd suggest punting for any case
where we have args partially in regs and partially in memory :-)
More thoughts when I can get an hour or two to remind myself how all
this stuff works on the PA.
I will note that testing on the PA is unlikely to show anything simply
because it uses 8 parameter passing registers. So it's rare to pass
anything in memory at all. Even rarer to have something partially in
memory and partially in registers.
Jeff
