[LLVMdev] Proposal for new Legalization framework

David Chisnall David.Chisnall at cl.cam.ac.uk
Thu Apr 25 08:28:42 PDT 2013


On 25 Apr 2013, at 16:00, Dan Gohman <dan433584 at gmail.com> wrote:

> Do you have a particular target in mind that we could discuss? Not all variances from the intersection of x86 and ARM are of the same nature; it's hard to talk in full generality here.
>  
> I think the correct answer (credit to Chris for this description) is that a legal type is one that (more or less) corresponds to a set of physical registers, and which the target is capable of loading, storing, and copying (possibly also inserting/extracting elements, for vector types).

I have an example in an architecture that we have here.  We have fat pointers, which we represent in the IR as pointers in a different address space.  It is very easy to model them in this way, and both LLVM IR and Clang are happy with the notion that you have different sized pointers in different address spaces (instcombine needed a little bit of hacking to tell it that it shouldn't turn inttoptr and ptrtoint sequences into bitcasts if the target and destination are different, which would be fixed by adding the proposed addrspacecast instruction), but as soon as you get to the target you have two assumptions that are firmly entrenched:

1) That all pointers for a given target are the same size (not true for us, or for some GPUs, or even for some microcontrollers)
2) That pointers are integers (not true for us, or any other architecture with fat pointers)

I dealt with the former by adding a new ValueType and custom lowering of pointers in the selected address space to it, but that's a bit ugly when the information about the pointer sizes is already present in the IR.  I haven't found a good solution to the latter, because lots of things use the is-a-pointer constraint in selection DAG patterns (e.g. loads, stores, atomics, and so on) and there is no simple way of modifying the pattern matching in TableGen to allow for multiple kinds of pointer.

I'm not sure how GPU back ends that want to select different load / store instructions for different address spaces are supposed to do it.

David

P.S. I'll be at EuroLLVM next week if anyone has good solutions or also encounters these problems and wants to chat about them.



More information about the llvm-dev mailing list