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