On 11/8/18 8:29 AM, Peter Bergner wrote:
> On 11/8/18 5:48 AM, Richard Biener wrote:
>> Esp. adding conflicts in a loop that says "See which defined values die
>> here."
>> is quite fishy.
>
> ..the original loop is dealing with some of the gory details you never read
> about in academic RA
On 11/8/18 10:19 AM, Renlin Li wrote:
>> Yes, this is the problem. We see from the dump, that r2040 does not
>> conflict with
>> hard reg r1:
>>
>> ;; a2040(r1597,l0) conflicts:
>> ;; total conflict hard regs:
>> ;; conflict hard regs:
> I think you should look for axxx(r2040, ..)?
>
>
Hi Peter,
On 11/08/2018 03:21 PM, Peter Bergner wrote:
On 11/8/18 4:57 AM, Renlin Li wrote:
I think I found the problem!
As described in the PR, a hard register is used in
an pre/post modify expression. The hard register is live, but updated.
In this case, we should make it conflicting with
On 11/8/18 4:57 AM, Renlin Li wrote:
> I think I found the problem!
>
> As described in the PR, a hard register is used in
> an pre/post modify expression. The hard register is live, but updated.
> In this case, we should make it conflicting with all pseudos live at
> that point. Does it make
On 11/8/18 5:48 AM, Richard Biener wrote:
> Err, that looks very much like a hack that manages to hide the issue.
It's true we do not want to hide the issue by adding unneeded conflicts,
since that can lead to unnecessary spills. However, ...
> Esp. adding conflicts in a loop that says "See
Hi Peter,
On 11/08/2018 12:35 PM, Peter Bergner wrote:
On 11/8/18 4:57 AM, Renlin Li wrote:
I think I found the problem!
As described in the PR, a hard register is used in
an pre/post modify expression. The hard register is live, but updated.
In this case, we should make it conflicting with
On 11/8/18 4:57 AM, Renlin Li wrote:
> I think I found the problem!
>
> As described in the PR, a hard register is used in
> an pre/post modify expression. The hard register is live, but updated.
> In this case, we should make it conflicting with all pseudos live at
> that point. Does it make
Hi,
On 11/06/2018 06:58 PM, Jeff Law wrote:
On 11/6/18 3:52 AM, Renlin Li wrote:
Hi Jeff & Peter,
On 11/05/2018 07:41 PM, Jeff Law wrote:
On 11/5/18 12:36 PM, Peter Bergner wrote:
On 11/5/18 1:20 PM, Jeff Law wrote:
On 11/1/18 4:07 PM, Peter Bergner wrote:
On 11/1/18 1:50 PM, Renlin Li
On 11/6/18 3:52 AM, Renlin Li wrote:
> Hi Jeff & Peter,
>
> On 11/05/2018 07:41 PM, Jeff Law wrote:
>> On 11/5/18 12:36 PM, Peter Bergner wrote:
>>> On 11/5/18 1:20 PM, Jeff Law wrote:
On 11/1/18 4:07 PM, Peter Bergner wrote:
> On 11/1/18 1:50 PM, Renlin Li wrote:
>> Is there any
On 11/6/18 6:23 AM, Renlin Li wrote:
> I just did a bootstrap again with everything up to r264897 which is Oct 6.
> it produce the ICE I mentioned on the PR87899.
>
> The first combiner patch on Oct 22.
Do the testsuite results (for disable-bootstrap builds) differ between
r264896 and r264897?
Hi Ramana,
On 11/06/2018 10:57 AM, Ramana Radhakrishnan wrote:
On Tue, Nov 6, 2018 at 10:52 AM Renlin Li wrote:
Hi Jeff & Peter,
On 11/05/2018 07:41 PM, Jeff Law wrote:
On 11/5/18 12:36 PM, Peter Bergner wrote:
On 11/5/18 1:20 PM, Jeff Law wrote:
On 11/1/18 4:07 PM, Peter Bergner wrote:
Hi Jeff & Peter,
On 11/05/2018 07:41 PM, Jeff Law wrote:
On 11/5/18 12:36 PM, Peter Bergner wrote:
On 11/5/18 1:20 PM, Jeff Law wrote:
On 11/1/18 4:07 PM, Peter Bergner wrote:
On 11/1/18 1:50 PM, Renlin Li wrote:
Is there any update on this issues?
arm-none-linux-gnueabihf native toolchain
On 11/5/18 12:36 PM, Peter Bergner wrote:
> On 11/5/18 1:20 PM, Jeff Law wrote:
>> On 11/1/18 4:07 PM, Peter Bergner wrote:
>>> On 11/1/18 1:50 PM, Renlin Li wrote:
Is there any update on this issues?
arm-none-linux-gnueabihf native toolchain has been mis-compiled for a
while.
>>>
On 11/5/18 1:20 PM, Jeff Law wrote:
> On 11/1/18 4:07 PM, Peter Bergner wrote:
>> On 11/1/18 1:50 PM, Renlin Li wrote:
>>> Is there any update on this issues?
>>> arm-none-linux-gnueabihf native toolchain has been mis-compiled for a while.
>>
>> From the analysis I've done, my commit is just
On 11/1/18 4:07 PM, Peter Bergner wrote:
> On 11/1/18 1:50 PM, Renlin Li wrote:
>> Is there any update on this issues?
>> arm-none-linux-gnueabihf native toolchain has been mis-compiled for a while.
>
> From the analysis I've done, my commit is just exposing latent issues
> in LRA. Can you try
Hi Peter,
On 11/01/2018 10:07 PM, Peter Bergner wrote:
On 11/1/18 1:50 PM, Renlin Li wrote:
Is there any update on this issues?
arm-none-linux-gnueabihf native toolchain has been mis-compiled for a while.
From the analysis I've done, my commit is just exposing latent issues
in LRA.
Yes,
On 11/1/18 1:50 PM, Renlin Li wrote:
> Is there any update on this issues?
> arm-none-linux-gnueabihf native toolchain has been mis-compiled for a while.
>From the analysis I've done, my commit is just exposing latent issues
in LRA. Can you try the patch I submitted here to see if it helps?
Hi Renlin,
On Thu, Nov 01, 2018 at 06:50:22PM +, Renlin Li wrote:
> I got the following dump from the test case.
>
> x1 is an early clobber operand in the inline assembly statement,
> r92 should conflict with x1?
Yes, I think so. Or LRA should not pick something that was already a
hard
Hi Peter,
Is there any update on this issues?
arm-none-linux-gnueabihf native toolchain has been mis-compiled for a while.
I got the following dump from the test case.
x1 is an early clobber operand in the inline assembly statement,
r92 should conflict with x1?
;; a0(r93,l0) conflicts:
On 10/11/18 10:40 PM, Jeff Law wrote:
> On 10/11/18 1:23 PM, Peter Bergner wrote:
>> * ira-lives (non_conflicting_reg_copy_p): Disable for non LRA targets.
> So this helped the alpha & hppa and sh4.
>
> I'm still seeing failures on the aarch64, s390x. No surprise on these
> since they use
On 10/12/18 10:38 AM, Peter Bergner wrote:
> On 10/11/18 3:51 PM, Vladimir Makarov wrote:
>> I think it has a sense because even if LRA has the same problem, it will be
>> hard to fix it in reload and LRA. Nobody worked on reload pass for a long
>> time and it is not worth to fix it because we
On 10/11/18 3:51 PM, Vladimir Makarov wrote:
> I think it has a sense because even if LRA has the same problem, it will be
> hard to fix it in reload and LRA. Nobody worked on reload pass for a long
> time and it is not worth to fix it because we are moving from reload.
[snip]
> In any case, the
> These are the easy ones (they default to reload):
>
> bergner@pike:~/gcc/gcc-fsf-mainline/gcc/config$ grep -r TARGET_LRA_P | grep
> false | sort alpha/alpha.c:#define TARGET_LRA_P hook_bool_void_false
> avr/avr.c:#define TARGET_LRA_P hook_bool_void_false
> bfin/bfin.c:#define TARGET_LRA_P
On 10/11/18 1:23 PM, Peter Bergner wrote:
> On 10/11/18 1:18 PM, Peter Bergner wrote:
>> Ok, after working in gdb, I see that the PA-RISC port still uses reload
>> and not LRA, but it too seems to have the same issue of reusing input
>> regs that have REG_DEAD notes, so the question still stands.
On 10/11/18 3:05 PM, Peter Bergner wrote:
> On 10/11/18 2:40 PM, Jeff Law wrote:
>> On 10/11/18 1:23 PM, Peter Bergner wrote:
>>> On 10/11/18 1:18 PM, Peter Bergner wrote:
Ok, after working in gdb, I see that the PA-RISC port still uses reload
and not LRA, but it too seems to have the
On 10/11/18 2:40 PM, Jeff Law wrote:
> On 10/11/18 1:23 PM, Peter Bergner wrote:
>> On 10/11/18 1:18 PM, Peter Bergner wrote:
>>> Ok, after working in gdb, I see that the PA-RISC port still uses reload
>>> and not LRA, but it too seems to have the same issue of reusing input
>>> regs that have
On 10/11/2018 03:23 PM, Peter Bergner wrote:
On 10/11/18 1:18 PM, Peter Bergner wrote:
Ok, after working in gdb, I see that the PA-RISC port still uses reload
and not LRA, but it too seems to have the same issue of reusing input
regs that have REG_DEAD notes, so the question still stands. It's
On 10/11/18 1:23 PM, Peter Bergner wrote:
> On 10/11/18 1:18 PM, Peter Bergner wrote:
>> Ok, after working in gdb, I see that the PA-RISC port still uses reload
>> and not LRA, but it too seems to have the same issue of reusing input
>> regs that have REG_DEAD notes, so the question still stands.
On 10/11/18 1:18 PM, Peter Bergner wrote:
> Ok, after working in gdb, I see that the PA-RISC port still uses reload
> and not LRA, but it too seems to have the same issue of reusing input
> regs that have REG_DEAD notes, so the question still stands. It's just
> that whatever fix we come up with
On 10/10/18 7:57 PM, Peter Bergner wrote:
> The problem is, that hard reg %r26 is defined in insn 32, to be used in
> insn 33, so using %r26 as the reload reg is wrong, because it will clobber
> the value we set in insn 32. Looking thru LRA, it looks like LRA assumes
> that for a reload, if one
On 10/8/18 9:52 AM, Jeff Law wrote:
> My tester is showing a variety of problems as well. hppa, sh4, aarch64,
> aarch64_be, alpha arm* and s390x bootstraps are all failing at various
> points. Others may trickle in over time, but clearly something went
> wrong recently. I'm going to start
On 10/8/18 8:43 AM, Christophe Lyon wrote:
> On Mon, 8 Oct 2018 at 16:13, Peter Bergner wrote:
>>
>> On 10/8/18 4:14 AM, Christophe Lyon wrote:
>>> Since r264897, we are seeing lots of regressions when bootstrapping on arm.
>>> There are execution errors as well as ICEs.
>>> A detailed list can
On 10/8/18 4:14 AM, Christophe Lyon wrote:
> Since r264897, we are seeing lots of regressions when bootstrapping on arm.
> There are execution errors as well as ICEs.
> A detailed list can be found at:
>
On Sat, 6 Oct 2018 at 04:38, Peter Bergner wrote:
>
> On 10/5/18 4:12 PM, Vladimir Makarov wrote:
> > On 10/05/2018 04:00 PM, Peter Bergner wrote:
> >> How about non_conflicting_reg_copy or non_conflicting_copy_insn?
> > OK. I like the first name more.
>
> Ok, I committed the patch using the
On 10/5/18 4:12 PM, Vladimir Makarov wrote:
> On 10/05/2018 04:00 PM, Peter Bergner wrote:
>> How about non_conflicting_reg_copy or non_conflicting_copy_insn?
> OK. I like the first name more.
Ok, I committed the patch using the first function name.
Thank you very much for the patch reviews and
On 10/05/2018 04:00 PM, Peter Bergner wrote:
On 10/5/18 1:32 PM, Vladimir Makarov wrote:
On 10/05/2018 12:40 PM, Peter Bergner wrote:
On 10/4/18 3:01 PM, Vladimir Makarov wrote:
IMHO, the name copy_insn_p is too common and confusing (we already have
functions copy_insn and copy_insn_1 in
On 10/5/18 1:32 PM, Vladimir Makarov wrote:
> On 10/05/2018 12:40 PM, Peter Bergner wrote:
>> On 10/4/18 3:01 PM, Vladimir Makarov wrote:
>>> IMHO, the name copy_insn_p is too common and confusing (we already have
>>> functions copy_insn and copy_insn_1 in GCC). The name does not reflect its
>>>
On 10/05/2018 12:40 PM, Peter Bergner wrote:
On 10/4/18 3:01 PM, Vladimir Makarov wrote:
IMHO, the name copy_insn_p is too common and confusing (we already have
functions copy_insn and copy_insn_1 in GCC). The name does not reflect its
result meaning. I would call it something like
On 10/4/18 3:01 PM, Vladimir Makarov wrote:
> IMHO, the name copy_insn_p is too common and confusing (we already have
> functions copy_insn and copy_insn_1 in GCC). The name does not reflect its
> result meaning. I would call it something like non_conflict_copy_source_reg
> although it is long.
On 10/03/2018 10:09 AM, Peter Bergner wrote:
Here is another updated PATCH 2 that is the same as the previous version,
but includes the modification to the expected output of i386/pr49095.c
test case, as H.J. has confirmed the code gen changes we are seeing on
are a good thing.
This patch
Here is another updated PATCH 2 that is the same as the previous version,
but includes the modification to the expected output of i386/pr49095.c
test case, as H.J. has confirmed the code gen changes we are seeing on
are a good thing.
This patch completed bootstrap and regtesting on
41 matches
Mail list logo
