[LLVMdev] Data/Address registers

[Ivan Llopard]

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 :-/.

>> 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 ?

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 ?

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