Richard Earnshaw writes:
> On 27/05/14 16:07, Richard Sandiford wrote:
>> Richard Sandiford writes:
>>> Richard Sandiford writes:
Does the following patch help?
>>>
>>> Bah, it won't of course: %i1 needs to be the operator.
>>
>> Here's v2. I tested that it worked for simple tests like:
>
On 27/05/14 16:07, Richard Sandiford wrote:
> Richard Sandiford writes:
>> Richard Sandiford writes:
>>> Does the following patch help?
>>
>> Bah, it won't of course: %i1 needs to be the operator.
>
> Here's v2. I tested that it worked for simple tests like:
>
> int f1 (int x, int y) { return
On 27/05/14 17:31, Richard Sandiford wrote:
> Richard Earnshaw writes:
>> On 27/05/14 17:09, Richard Sandiford wrote:
>>> Richard Earnshaw writes:
On 27/05/14 16:27, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 04:15:47PM +0100, Richard Earnshaw wrote:
>> On 27/05/14 15:08, Richard
The patch also fixes the arm-none-eabi build failures I've seen.
Thanks,
Yufeng
On 05/27/14 16:07, Richard Sandiford wrote:
Richard Sandiford writes:
Richard Sandiford writes:
Does the following patch help?
Bah, it won't of course: %i1 needs to be the operator.
Here's v2. I tested that
On 27 May 2014 17:07, Richard Sandiford wrote:
> Richard Sandiford writes:
>> Richard Sandiford writes:
>>> Does the following patch help?
>>
>> Bah, it won't of course: %i1 needs to be the operator.
>
> Here's v2. I tested that it worked for simple tests like:
>
I confirm that the compiler no
Richard Earnshaw writes:
> On 27/05/14 17:09, Richard Sandiford wrote:
>> Richard Earnshaw writes:
>>> On 27/05/14 16:27, Jakub Jelinek wrote:
On Tue, May 27, 2014 at 04:15:47PM +0100, Richard Earnshaw wrote:
> On 27/05/14 15:08, Richard Sandiford wrote:
>> Hmm, is this because of "i
On 27/05/14 17:09, Richard Sandiford wrote:
> Richard Earnshaw writes:
>> On 27/05/14 16:27, Jakub Jelinek wrote:
>>> On Tue, May 27, 2014 at 04:15:47PM +0100, Richard Earnshaw wrote:
On 27/05/14 15:08, Richard Sandiford wrote:
> Hmm, is this because of "insn_enabled"? If so, how did tha
Richard Earnshaw writes:
> On 27/05/14 16:27, Jakub Jelinek wrote:
>> On Tue, May 27, 2014 at 04:15:47PM +0100, Richard Earnshaw wrote:
>>> On 27/05/14 15:08, Richard Sandiford wrote:
Hmm, is this because of "insn_enabled"? If so, how did that work before
the patch? LRA already assumed
On 27/05/14 16:50, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 04:40:13PM +0100, Richard Earnshaw wrote:
>>
>> The @code{enabled} insn attribute may be used to disable certain insn
>> alternatives for machine-specific reasons.
>>
>>
>> The rest of the text just says what happens when this is d
On Tue, May 27, 2014 at 04:40:13PM +0100, Richard Earnshaw wrote:
>
> The @code{enabled} insn attribute may be used to disable certain insn
> alternatives for machine-specific reasons.
>
>
> The rest of the text just says what happens when this is done and then
> gives an example usage. It does
On 27/05/14 16:27, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 04:15:47PM +0100, Richard Earnshaw wrote:
>> On 27/05/14 15:08, Richard Sandiford wrote:
>>> Hmm, is this because of "insn_enabled"? If so, how did that work before
>>> the patch? LRA already assumed that the "enabled" attribute di
On Tue, May 27, 2014 at 04:15:47PM +0100, Richard Earnshaw wrote:
> On 27/05/14 15:08, Richard Sandiford wrote:
> > Hmm, is this because of "insn_enabled"? If so, how did that work before
> > the patch? LRA already assumed that the "enabled" attribute didn't depend
> > on the operands.
>
> Huh!
On 27/05/14 15:08, Richard Sandiford wrote:
> Hmm, is this because of "insn_enabled"? If so, how did that work before
> the patch? LRA already assumed that the "enabled" attribute didn't depend
> on the operands.
Huh! "enabled" can be applied to each alternative. Alternatives are
selected base
Richard Sandiford writes:
> Richard Sandiford writes:
>> Does the following patch help?
>
> Bah, it won't of course: %i1 needs to be the operator.
Here's v2. I tested that it worked for simple tests like:
int f1 (int x, int y) { return x + (y << 4); }
int f2 (int x, int y) { return x - (y << 4
On 27 May 2014 15:37, Ramana Radhakrishnan wrote:
> On Tue, May 27, 2014 at 2:12 PM, Christophe Lyon
> wrote:
>> Hi,
>>
>> Commits 210964 and 210965 for this patch have broken GCC build on arm*
>> targets.
>> For instance on target arm-none-linux-gnueabi, when creating
>> unwind-arm.o, I can see
Richard Sandiford writes:
> Does the following patch help?
Bah, it won't of course: %i1 needs to be the operator.
Richard
Christophe Lyon writes:
> Hi,
>
> Commits 210964 and 210965 for this patch have broken GCC build on arm*
> targets.
Could you send me the .i?
> For instance on target arm-none-linux-gnueabi, when creating
> unwind-arm.o, I can see:
> /tmp/5673443_3.tmpdir/aci-gcc-fsf/sources/gcc-fsf/tru
On Tue, May 27, 2014 at 2:12 PM, Christophe Lyon
wrote:
> Hi,
>
> Commits 210964 and 210965 for this patch have broken GCC build on arm*
> targets.
> For instance on target arm-none-linux-gnueabi, when creating
> unwind-arm.o, I can see:
> /tmp/5673443_3.tmpdir/aci-gcc-fsf/sources/gcc-fsf
Hi,
Commits 210964 and 210965 for this patch have broken GCC build on arm* targets.
For instance on target arm-none-linux-gnueabi, when creating
unwind-arm.o, I can see:
/tmp/5673443_3.tmpdir/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/lra.c:1362
0x8e3bcd process_insn_for_elimination
/t
On 05/20/14 15:36, Richard Sandiford wrote:
This is OK for the trunk (referring to the follow-up message which fixed
EWRONGPATCH.
Sorry, while working on the follow-up LRA patch, I realised I hadn't
accounted for target changes that happen directly via target_reinit
(rather than SWITCHABLE_TARG
Jeff Law writes:
> On 05/20/14 02:16, Richard Sandiford wrote:
>> get_attr_enabled was showing up high in a -O0 compile of fold-const.ii.
>> At the moment, extract_insn calls this function for every alternative
>> on each extraction, which can be expensive for instructions like
>> moves that have
On 05/20/14 02:16, Richard Sandiford wrote:
get_attr_enabled was showing up high in a -O0 compile of fold-const.ii.
At the moment, extract_insn calls this function for every alternative
on each extraction, which can be expensive for instructions like
moves that have many alternatives.
The attrib
On May 20, 2014, at 1:17 AM, Richard Sandiford
wrote:
>> The patch gives a consistent compile-time improvement of about ~3.5%
>> on the -O0 fold-const.ii test case.
3.5 alone is really nice and 3.5 on top of 3.5 is amazing.
Richard Sandiford writes:
> get_attr_enabled was showing up high in a -O0 compile of fold-const.ii.
> At the moment, extract_insn calls this function for every alternative
> on each extraction, which can be expensive for instructions like
> moves that have many alternatives.
>
> The attribute is o
get_attr_enabled was showing up high in a -O0 compile of fold-const.ii.
At the moment, extract_insn calls this function for every alternative
on each extraction, which can be expensive for instructions like
moves that have many alternatives.
The attribute is only supposed to depend on the insn cod
25 matches
Mail list logo
