On 27 November 2013 19:13, Jeff Law wrote:
> On 11/27/13 10:30, Yvan Roux wrote:
>>>
>>> Please include either the patch you are pinging or at the least a link to
>>> it
>>> in the archives.
>>
>>
>> Ok, sorry for that, here is the patch and Changelog
>>
>> Yvan
>>
>>
>> 2013-11-17 Yvan Roux
>>
> On 11/27/13 10:30, Yvan Roux wrote:
> >>Please include either the patch you are pinging or at the least a link to it
> >>in the archives.
> >
> >Ok, sorry for that, here is the patch and Changelog
> >
> >Yvan
> >
> >
> >2013-11-17 Yvan Roux
> >
> > * config/arm/arm.md (store_minmaxsi):
On 11/27/13 10:30, Yvan Roux wrote:
Please include either the patch you are pinging or at the least a link to it
in the archives.
Ok, sorry for that, here is the patch and Changelog
Yvan
2013-11-17 Yvan Roux
* config/arm/arm.md (store_minmaxsi): Use only when
optimize_f
> Please include either the patch you are pinging or at the least a link to it
> in the archives.
Ok, sorry for that, here is the patch and Changelog
Yvan
2013-11-17 Yvan Roux
* config/arm/arm.md (store_minmaxsi): Use only when
optimize_function_for_size_p.
diff --git a/gcc/
On 11/27/13 03:18, Yvan Roux wrote:
Ping.
On 19 November 2013 09:52, Yvan Roux wrote:
yep, all good performance-wise :)
Great, Thanks Kyrill.
Ok for trunk ?
Please include either the patch you are pinging or at the least a link
to it in the archives.
jeff
Ping.
On 19 November 2013 09:52, Yvan Roux wrote:
>> yep, all good performance-wise :)
>
> Great, Thanks Kyrill.
>
> Ok for trunk ?
>
> Yvan
> yep, all good performance-wise :)
Great, Thanks Kyrill.
Ok for trunk ?
Yvan
On 18/11/13 09:14, Kyrill Tkachov wrote:
On 18/11/13 08:37, Yvan Roux wrote:
So, the validation is ok with this patch, I'm just not able to say if
the original performance issue is still fixed with it. Could you
check it Kyrylo ?
Hi Yvan,
I'll run the benchmark today to confirm the performance
> Hi Yvan,
> I'll run the benchmark today to confirm the performance, but from compiling
> some code sequences that exhibited the bad behaviour in the past, I see that
> this patch still fixes the issues. store_minmaxsi is not generated when
> optimising for speed.
Ok Cool, Thanks Kyrill
Cheers,
On 18/11/13 08:37, Yvan Roux wrote:
So, the validation is ok with this patch, I'm just not able to say if
the original performance issue is still fixed with it. Could you
check it Kyrylo ?
Hi Yvan,
I'll run the benchmark today to confirm the performance, but from compiling some
code sequences
So, the validation is ok with this patch, I'm just not able to say if
the original performance issue is still fixed with it. Could you
check it Kyrylo ?
Yvan
2013-11-17 Yvan Roux
* config/arm/arm.md (store_minmaxsi): Use only when
optimize_function_for_size_p.
On 15 Novembe
> Sometimes 4 will be needed, since both original register values may
> remain live.
Indeed.
> However, I'm inclined to agree that while it should be possible to
> decide at the *function* level whether or not an insn is valid, doing so
> at the block level is probably unsafe.
Ok, so the attache
On 15/11/13 14:19, Yvan Roux wrote:
> Hi,
>
> I'm agree. I looked at the ARM backend and it occurs that the usage
> of optimize_insn_for_size_p() was added to only use store_minmax in
> cold path because of some performance issue. But in any case its
> usage doesn't shrink the number of instruct
Hi,
I'm agree. I looked at the ARM backend and it occurs that the usage
of optimize_insn_for_size_p() was added to only use store_minmax in
cold path because of some performance issue. But in any case its
usage doesn't shrink the number of instruction, if we are in ARM mode
3 are needed : 1 comp
Steven Bosscher wrote:
>Hello,
>
>This patch is necessary to make ARM pass the test suite with LRA
>enabled. The symptom is recog failing to recognize a store_minmaxsi
>insn, see:
> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00725.html
>
>But I am not sure if that's also the root cause of the pr
15 matches
Mail list logo
