public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: pinskia@gmail.com
To: Richard Biener <richard.guenther@gmail.com>
Cc: Thomas Preud'homme <thomas.preudhomme@arm.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Fix PR54733 Optimize endian independent load/store
Date: Fri, 16 May 2014 10:56:00 -0000	[thread overview]
Message-ID: <EF3B84D2-BB18-405B-8CE3-3C1F2A792473@gmail.com> (raw)
In-Reply-To: <CAFiYyc1-5KbvVXqiQKu3aVn_X0RKvvtJn4hBtADp5eA3QFEb4A@mail.gmail.com>



> On May 16, 2014, at 3:48 AM, Richard Biener <richard.guenther@gmail.com> wrote:
> 
> On Fri, May 16, 2014 at 12:07 PM, Thomas Preud'homme
> <thomas.preudhomme@arm.com> wrote:
>> Ping?
> 
> Sorry ...
> 
>> Best regards,
>> 
>> Thomas Preud'homme
>> 
>>> -----Original Message-----
>>> From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches-
>>> owner@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>>> Sent: Friday, May 09, 2014 6:26 PM
>>> To: GCC Patches
>>> Subject: RE: [PATCH] Fix PR54733 Optimize endian independent load/store
>>> 
>>> Sorry, took longer than expected as I got distracted by some other patch.
>>> I merged the whole patchset in a single patch as I was told the current setup
>>> is actually more difficult to read.
>>> 
>>> Here are the updated ChangeLogs:
>>> 
>>> *** gcc/ChangeLog ***
>>> 
>>> 2014-05-09  Thomas Preud'homme  <thomas.preudhomme@arm.com>
>>> 
>>>      PR tree-optimization/54733
>>>      * expr.c (get_inner_reference): Add a parameter to control whether
>>> a
>>>      MEM_REF should be split into base + offset.
>>>      * tree.h (get_inner_reference): Default new parameter to false.
>>>      * tree-ssa-math-opts.c (nop_stats): New "bswap_stats" structure.
>>>      (CMPNOP): Define.
>>>      (find_bswap_or_nop_load): New.
>>>      (find_bswap_1): Renamed to ...
>>>      (find_bswap_or_nop_1): This. Also add support for memory source.
>>>      (find_bswap): Renamed to ...
>>>      (find_bswap_or_nop): This. Also add support for memory source and
>>>      detection of bitwise operations equivalent to load in host endianness.
>>>      (execute_optimize_bswap): Likewise. Also move its leading
>>> comment back
>>>      in place and split statement transformation into ...
>>>      (bswap_replace): This. Add assert when updating bswap_stats.
>>> 
>>> *** gcc/testsuite/ChangeLog ***
>>> 
>>> 2014-05-09  Thomas Preud'homme  <thomas.preudhomme@arm.com>
>>> 
>>>      PR tree-optimization/54733
>>>      * gcc.dg/optimize-bswapdi-3.c: New test to check extension of
>>> bswap
>>>      optimization to support memory sources and bitwise operations
>>>      equivalent to load in host endianness.
>>>      * gcc.dg/optimize-bswaphi-1.c: Likewise.
>>>      * gcc.dg/optimize-bswapsi-2.c: Likewise.
>>>      * gcc.c-torture/execute/bswap-2.c: Likewise.
>>> 
>>> Ok for trunk?
> 
> Ok, I now decided otherwise and dislike the new parameter to
> get_inner_reference.  Can you please revert that part and just
> deal with a MEM_REF result in your only caller?
> 
> And (of course) I found another possible issue.  The way you
> compute load_type and use it here:
> 
> +      /* Perform the load.  */
> +      load_offset_ptr = build_int_cst (n->alias_set, 0);
> +      val_expr = fold_build2 (MEM_REF, load_type, addr_tmp,
> +                             load_offset_ptr);
> 
> makes the load always appear aligned according to the mode of
> load_type.  On strict-alignment targets this may cause faults.
> 
> So what you have to do is either (simpler)
> 
>   unsigned int align = get_pointer_alignment (addr_tmp);
>   tree al_load_type = load_type;
>   if (align < TYPE_ALIGN (load_type))
>     al_load_type = build_aligned_type (load_type, align);
> ...
>    val_expr = fold_build2 (MEM_REF, al_load_type, addr_tmp,
>                                     load_offset_ptr);
> 
> or keep track of the "first" actual load and use
> 
>   unsigned int align = get_object_alignment (that_first_load);
> 
> "first" in the one that corresponds to addr_tmp.  From that there
> is a much better chance to derive good alignment values.
> 
> Of course on STRICT_ALIGNMENT targets a not aligned load
> will be decomposed again, so eventually doing the transformation
> may no longer be profitable(?).

Not always decomposed. On MIPS, it should using the load/store left/right instructions for unaligned load/stores which is normally better than decomposed load/stores. So having a cost model would be nice. 

Thanks,
Andrew

> 
> Thanks and sorry again for the delay.
> 
> Otherwise the patch looks good to me.
> 
> Richard.
> 
>>> Best regards,
>>> 
>>> Thomas
>>> 
>>>> -----Original Message-----
>>>> From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches-
>>>> owner@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>>>> Sent: Monday, May 05, 2014 7:30 PM
>>>> To: GCC Patches
>>>> Subject: RE: [PATCH][2/3] Fix PR54733 Optimize endian independent
>>>> load/store
>>>> 
>>>> I found a way to improve the function find_bswap/find_bswap_or_nop
>>>> and reduce its size. Please hold for the review, I will post an updated
>>>> version as soon as I finish testing.
>>>> 
>>>> Best regards,
>>>> 
>>>> Thomas Preud'homme
>> 
>> 

  reply	other threads:[~2014-05-16 10:56 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09 10:26 Thomas Preud'homme
2014-05-16 10:07 ` Thomas Preud'homme
2014-05-16 10:48   ` Richard Biener
2014-05-16 10:56     ` pinskia [this message]
2014-05-16 11:03       ` Richard Biener
2014-05-16 11:14         ` Richard Biener
2014-05-16 16:59           ` pinskia
2014-05-19  2:49             ` Thomas Preud'homme
2014-05-20  2:50             ` Andrew Pinski
2014-05-19  9:30           ` Thomas Preud'homme
2014-05-19  9:46             ` Richard Biener
2014-05-20  2:46         ` Thomas Preud'homme
2014-05-20  9:06           ` Richard Biener
2014-05-20 10:29             ` Thomas Preud'homme
2014-05-21  1:00               ` Thomas Preud'homme
2014-05-22 10:07                 ` Richard Biener
2014-05-23  3:36                   ` Thomas Preud'homme
2014-05-26 10:57                     ` Christophe Lyon
2014-05-26 11:06                       ` Thomas Preud'homme
2014-05-27  7:23                         ` Thomas Preud'homme
2014-05-27 14:35                           ` Christophe Lyon
2014-05-27 16:45                           ` Andreas Schwab
2014-05-29  8:18                             ` Thomas Preud'homme
2014-05-29  8:52                               ` Andreas Schwab
2014-05-29  9:58                                 ` Thomas Preud'homme
2014-06-02 13:57                                   ` Christophe Lyon
2014-06-04  7:04                                     ` Thomas Preud'homme
2014-06-04  9:52                                       ` Richard Biener
2014-06-06 10:45                                         ` Thomas Preud'homme
2014-05-24 18:56                 ` Andreas Schwab
  -- strict thread matches above, loose matches on Subject: below --
2014-03-19  7:24 Thomas Preud'homme

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EF3B84D2-BB18-405B-8CE3-3C1F2A792473@gmail.com \
    --to=pinskia@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    --cc=thomas.preudhomme@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).