Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane

From: Ahmed Bougacha <ahmed.bougacha <at> gmail.com>
Subject: FYI out-of-tree/in-tree target maintainers: setLoadExtAction now takes two MVTs.
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Thursday 8th January 2015 01:09:17 UTC (over 3 years ago)
Hi all,

I made a change to get/setLoadExtAction in r225421 to be able to also
specify value type (rather than just memory type) legality.

The de facto previous behavior was to ignore the value type, and only
worry about the memory type.

To match that, I mechanically changed all instances of
setLoadExtAction in the in-tree codebase. However, I'd guess there are
lots of cases where the legality should be restricted, and maybe some
where it should be extended

This change was motivated by X86 having some but not all value types
legal for an extload from a given memory type.  Maybe your target is
in a similar situation.

For X86, ARM, and AArch64: I'll take care of changing the backends to
take advantage of the finer API.




Maintainers of other in-tree targets: please do the same.  Also,
please double-check the mechanical change mentioned above.  As-is,
there shouldn't be any functional change.


Out-of-tree maintainers: the simplest change to get your target to
compile is to turn:

  setLoadExtAction(..., VT, ...);

into:

  for (MVT InnerVT : MVT::all_valuetypes())
    setLoadExtAction(..., InnerVT, VT, ...);

You might want to:
- use a finer-grained MVT range; for instance, if VT is a vector type,
use MVT::vector_valuetypes().
- use target knowledge to make the setLoadExtAction calls more precise.


-Ahmed
 
CD: 11ms