Add a pass to convert aggregate loads/stores into scalar load stores

[Philip Reames]

On 10/30/2014 09:58 PM, deadal nix wrote:
>
>
> 2014-10-30 21:52 GMT-07:00 Hal Finkel <hfinkel at anl.gov 
> <mailto:hfinkel at anl.gov>>:
>
>     ----- Original Message -----
>     > From: "deadal nix" <deadalnix at gmail.com
>     <mailto:deadalnix at gmail.com>>
>     > To: "Philip Reames" <listmail at philipreames.com
>     <mailto:listmail at philipreames.com>>
>     > Cc: "Chandler Carruth" <chandlerc at google.com
>     <mailto:chandlerc at google.com>>, "Hal Finkel" <hfinkel at anl.gov
>     <mailto:hfinkel at anl.gov>>, "llvm-commits"
>     > <llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>>
>     > Sent: Thursday, October 30, 2014 11:45:12 PM
>     > Subject: Re: Add a pass to convert aggregate loads/stores into
>     scalar load stores
>     >
>     > Option 4 - Transform to series of smaller integer loads
>     > - This appears to be what this patch implements. Not entirely sure
>     > why this was chosen.
>     >
>     >
>     > Yes, this is what this diff is doing.
>     >
>     >
>     > This option allow to keep pointerness of load/stores (it could be
>     > refined in this patch, but the idea is there). It also avoid to
>     > generate a bunch of small load when a big load would suffice.
>     >
>     >
>     > Making a big load of iN (option 2) is also reasonable, but in this
>     > case, the load won't respect the target alignment's constraints. I
>     > thought it was a problem so I went for the option 3 instead.
>
>     You can manually set the alignment on the load to be whatever you
>     need (down to align 1).
>
>      -Hal
>
>
> I wasn't sure how well it is supported and wanted to avoid to open a 
> new can of worms. If you think this is a better approach, I can update 
> the diff in that direction.
I would not advice investing effort in revising the existing patch until 
we settle on an overall approach.

p.s. Feel free to argue in favor of the current approach.  The "it's 
here and works, even if not ideal" argument is a worthy one which hasn't 
really been made.

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141031/03dd4f07/attachment.html>