[LLVMdev] Data/Address registers

[Jim Grosbach]

On Mar 7, 2012, at 6:23 AM, Ivan Llopard <ivanllopard at gmail.com> wrote:

> Hi Jim,
> 
> Thanks for your response.
> 
> Le 06/03/2012 22:54, Jim Grosbach a écrit :
>> Hi Ivan,
>> On Mar 3, 2012, at 4:48 AM, Ivan Llopard<ivanllopard at gmail.com>  wrote:
>> 
>>> Hi,
>>> 
>>> I'm facing a problem in llvm while porting it to a new target and I'll
>>> need some support.
>>> We have 2 kind of register, one for general purposes (i.e. arithmetic,
>>> comparisons, etc.) and the other for memory addressing.
>> OK. Separate register classes should be able to handle this.
>> 
>>> Cross copies are not allowed (no data path).
>> You mean you can't copy directly from a general purpose register to an address register? That's an unfortunate architectural quirk. You may have to write some interesting and potentially ugly code in copyPhysReg() to handle that.
>> 
> 
> Actually, I can't copy them in any way, it's just impossible :-/.

Do you have load/store instructions for each register class? Worst case you could do a push/pop pair on the stack. It's really, really important that there be a way, even a very expensive way, to do this.

> 
>>> We use clang 3.0 to produce assembler code.
>>> Because both registers have the same size and type (i16), I don't know
>>> what would be the best solution to distinguish them in order to match
>>> the right instructions.
>> The register classes should take care of this.
> 
> I tried but IMO the matching rule should be context-dependent, i.e. an i16 addition should match machine additions with operands being either data registers or address registers depending on its usage. Even if I look at index operands of load/stores (into the DAG) to match target's addressing modes, I can't assume that some operations are not being used for something else than basic arithmetics (like comparisons which are not supported for address regs). Is it still possible to get ride of this with register classes ?

It should be, yes. For a contrived example of a simple add-immediate instruction for each:

def ADD_address_reg: myBaseInstrClass<(outs ADDR_REG:$dst), (ins ADDR_REG:$src, i32imm:$imm), [(set ADDR_REG:$dst, (add ADDR_REG:$dst, i32imm:$imm)]>;
def ADD_general_reg: myBaseInstrClass<(outs GPR:$dst), (ins GPR:$src, i32imm:$imm),  [(set GPR:$dst, (add GPR:$dst, i32imm:$imm)]>;

Likewise, other operations that can target either register class should have a variant for each. ISel will choose the appropriate one based on the rest of the operands.

> I can make a pass before ISel to annotate the code identifying those registers which are only used for addressing (by doing a simple data-flow analysis), can it help ISelector later ?
> Because I could not find how to get metadata from the DAG to drive matching rules or lowering phases, is it possible ? How is metadata transferred to the DAG, where should I look for it ?
> 

Metadata should not be necessary for this. In general, metadata should never be used for anything that's required information, only for optional information. I.e., if it's stripped out of the IR, the backend should still generate correct code.

-Jim

> Ivan
> 
>>> Moreover, the standard pointer arithmetic is not
>>> enough for us (we need to support modulo operations also).
>>> I thought that I could manually match every arithmetic operation while
>>> matching the addressing mode but it doesn't work because intermediate
>>> results are sometimes reused for other purposes (e.g. comparisons).
>> I suggest getting things working correctly first and then coming back to things like this as an optimization.
>> 
>>> Do I need to add another type to clang/llvm ?
>>> 
>> Unlikely.
>> 
>> Regards,
>>  Jim
>> 
>> 
>>> Thanks in advance,
>>> 
>>> Ivan
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu          http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev