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
24 matches
Mail list logo
