[llvm] r220141 - Preserve AA metadata when combining (cast (load (...))) -> (load (cast

Chandler Carruth chandlerc at gmail.com
Sun Oct 19 02:53:51 PDT 2014


On Sat, Oct 18, 2014 at 11:48 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "Chandler Carruth" <chandlerc at gmail.com>
> > To: llvm-commits at cs.uiuc.edu
> > Sent: Saturday, October 18, 2014 6:00:12 AM
> > Subject: [llvm] r220141 - Preserve AA metadata when combining (cast
> (load     (...))) -> (load (cast
> >
> > Author: chandlerc
> > Date: Sat Oct 18 06:00:12 2014
> > New Revision: 220141
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=220141&view=rev
> > Log:
> > Preserve AA metadata when combining (cast (load (...))) -> (load
> > (cast
> > (...))).
>
> This is obviously good, but there is also other metadata that can be
> preserved here (like llvm.mem.parallel_loop_access, invariant.load, etc.),
> and we should do so. I think that it might be better to "drop and copy"
> instead of doing it this way. We have a
> Instruction::dropUnknownMetadata(ArrayRef<unsigned> KnownIDs) function now
> which should make this easy.


Yea.

The more I think about it, the less I can dream up any metadata that will
ever *not* be valid to propagate here. But of course, we need to be
conservatively correct. I don't think dropUnknownMetadata is the right
approach here, not the least because we don't have any way to copy it.
Instead, I think a copy with an explicit switch is the right approach.
Then, if I change the enum of MD kinds to be a named enum I can get a
warning if anyone ever updates the set of metadata with kinds in that enum
and fails to add it to this switch.

I'm switching the code to use a switch and preserve all of the currently
tagged kinds of metadata. Does going further and using a named enum seem
reasonable to you as well? If so, I'll make and document that change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141019/cd3b766d/attachment.html>


More information about the llvm-commits mailing list