Hi Vladimir,
Thank you for explain it.
I have a few comments inlined.
On 26/02/16 23:54, Vladimir Makarov wrote:
Thanks for working on this and providing a good description of the
problem. Could you fill a PR and provide a test even if you can not
reduce it.
I will fill a PR. Try to reduc
On 02/26/2016 07:54 AM, Renlin Li wrote:
Hi all,
I admit that, the title looks a little bit confusing.
The situation is like this,
To make insn_1 strict, lra generates a new insn_1_reload insn.
In insn_1_reload, there is a scratch operand with this form
clobber (match_scratch:MODE x "=&r")
Whe
Hi Richard,
On 26/02/16 12:57, Richard Biener wrote:
On Fri, Feb 26, 2016 at 1:54 PM, Renlin Li wrote:
I have checked, x86, arm, aarch64, mips, arc all have such patterns. But
it's
not triggered. In my case, it's triggered by compiling glibc with local
change.
Please extract a testcase fro
On Fri, Feb 26, 2016 at 1:54 PM, Renlin Li wrote:
> Hi all,
>
> I admit that, the title looks a little bit confusing.
>
> The situation is like this,
> To make insn_1 strict, lra generates a new insn_1_reload insn.
> In insn_1_reload, there is a scratch operand with this form
> clobber (match_scra
Hi all,
I admit that, the title looks a little bit confusing.
The situation is like this,
To make insn_1 strict, lra generates a new insn_1_reload insn.
In insn_1_reload, there is a scratch operand with this form
clobber (match_scratch:MODE x "=&r")
When lra tries to reload insn_1_reload in lat
