2012/6/30 Georg-Johann Lay :
> Is there a special reason to restrict it to SYMBOL_REF?
> Doesn't the same issue occur with, e.g.
> (const (plus (symbol_ref const_int))) or label_ref?
Hi!
We have added splits for symbol_ref plus const and label_ref. With
this patch, assembly code and oprofile data
On 06/29/2012 06:31 PM, Ramana Radhakrishnan wrote:
Ok with this comment?
+;; Split symbol_refs at the later stage (after cprop), instead of
generating
+;; movt/movw pair directly at expand. Otherwise corresponding high_sum
+;; and lo_sum would be merged back into memory load at cprop. Howeve
Dmitry Melnik schrieb:
On 06/27/2012 07:53 PM, Richard Earnshaw wrote:
Please update the ChangeLog entry (it's not appropriate to mention
Sourcery G++) and add a comment as Steven has suggested.
Otherwise OK.
Updated.
Ok to commit now?
--
Best regards,
Dmitry
2009-05-29 Julian Brown
On 29 June 2012 14:48, Dmitry Melnik wrote:
>
> On 06/27/2012 07:55 PM, Ramana Radhakrishnan wrote:
>
>> I must admit that I had been suggesting to Zhenqiang about turning
>> this off by tightening the movsi_insn predicates rather than adding a
>> split, but given that it appears to produce enough
> +;; Split symbol_refs at the later stage (after cprop), instead of generating
> +;; movt/movw pair directly at expand. Otherwise corresponding high_sum
> +;; and lo_sum would be merged back into memory load at cprop. However,
I would rewrite part of your comment as
> +;; movt/movw is preferab
On 06/27/2012 07:53 PM, Richard Earnshaw wrote:
Please update the ChangeLog entry (it's not appropriate to mention
Sourcery G++) and add a comment as Steven has suggested.
Otherwise OK.
Updated.
Ok to commit now?
--
Best regards,
Dmitry
2009-05-29 Julian Brown
gcc/
* config/arm/arm
On 06/27/2012 07:55 PM, Ramana Radhakrishnan wrote:
> I must admit that I had been suggesting to Zhenqiang about turning
> this off by tightening the movsi_insn predicates rather than adding a
> split, but given that it appears to produce enough benefit in this
> case I don't have any reasons to
On 27 June 2012 15:58, Dmitry Melnik wrote:
> Hi,
>
> We'd like to note about CodeSourcery's patch for ARM backend, from which GCC
> mainline can gain 4% on SPEC2K INT:
> http://cgit.openembedded.org/openembedded/plain/recipes/gcc/gcc-4.5/linaro/gcc-4.5-linaro-r99369.patch
> (also the patch is att
On 27/06/12 15:58, Dmitry Melnik wrote:
> Hi,
>
> We'd like to note about CodeSourcery's patch for ARM backend, from which
> GCC mainline can gain 4% on SPEC2K INT:
> http://cgit.openembedded.org/openembedded/plain/recipes/gcc/gcc-4.5/linaro/gcc-4.5-linaro-r99369.patch
>
> (also the patch is a
On Wed, 27 Jun 2012 18:58:36 +0400
Dmitry Melnik wrote:
> This patch can be applied to current trunk and passes regtest
> successfully on qemu-arm.
> Maybe it will be good to have it in trunk?
> If everybody agrees, we can take care of committing it.
No objection from me (as the original author
On Wed, Jun 27, 2012 at 4:58 PM, Dmitry Melnik wrote:
> This patch can be applied to current trunk and passes regtest successfully
> on qemu-arm.
> Maybe it will be good to have it in trunk?
> If everybody agrees, we can take care of committing it.
If the patch is approved, can you please add a b
Hi,
We'd like to note about CodeSourcery's patch for ARM backend, from which
GCC mainline can gain 4% on SPEC2K INT:
http://cgit.openembedded.org/openembedded/plain/recipes/gcc/gcc-4.5/linaro/gcc-4.5-linaro-r99369.patch
(also the patch is attached).
Originally, we noticed that GNU Go works 6
12 matches
Mail list logo
