Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly. Mostly just a stub.
|
From: Stepan D. <stp...@na...> - 2013-06-25 14:33:53
|
And... I mentioned Rick Mann, not John, since Rick said he would like to
help us with frontend. My fault.
-Stepan.
Stepan Dyatkovskiy wrote:
> Hi Borja,
>
> > Ahh, I didn't know avr-gcc was buggy on this feature, that's probably
>> the reason for why the code i pasted in my previous email didn't work.
> ...
>> What's wrong with clang? I fixed clang inline asm support back on
>> friday, so is there anything else that is broken?
> It should emit '*Q' instead of 'Q'. That's why code from prev. email
> didn't work, just compare -emit-llvm -S output of avr-clang with other
> backends,
>
> > About the getPointerRegClass function, what is it used for? Also, please
> > move the implementation to the cpp file instead of leaving it in the .h.
> Currently, it is used in registers coelescing pass. While being
> registers inflating, llvm lookups all register uses. If it found that
> register is used by inline-asm as memory operand, it requests the
> pointer class with this method (I think the largest one). But may be in
> future this method will be used in more cases.
>
> avr-gcc has buggy implementation of memory constraint, that's why
> avr-libs doesn't use it at all. We have a chance to be first here :-)
>
> -Stepan
>
>>
>>
>>
>> 2013/6/25 Stepan Dyatkovskiy <stp...@na...
>> <mailto:stp...@na...>>
>>
>> Hi Borja.
>> This is new patch. Seems I've moved memory constraint implementation
>> to the same level like all other constraints. Note avr-gcc has buggy
>> implementation of memory constraint, that's why *avr-libc doesn't
>> use it*.
>>
>> I removed restriction for Y,Z in getLargestLegalSuperClass, so these
>> registers could be inflated now. But there was unimplemented
>> getPointerRegClass method in AVRRegistersInfo. So currently I have
>> restricted it to Y and Z. Though suppose we can extend it in future
>> to XYZ set.
>> Look changes in inline-asm.ll to see what exactly is supported now.
>>
>> About clang.
>> May be we ask John Myers to fix clang support for inline asm?
>>
>> -Stepan.
>>
>>
>> Stepan Dyatkovskiy wrote:
>>
>> The patch. Forgot to attach it.
>> -Stepan.
>> Stepan Dyatkovskiy wrote:
>>
>> Hi Borja,
>>
>> > What happens in your example above when you use a real
>> instruction
>> like
>>
>> for example LDD? Does it still use GPR8 regs? To me it's
>> weird that if
>> you use a real instruction where operands are clearly
>> defined in the td
>> file the instruction selector uses an invalid regclass.
>>
>>
>> There are two kinds of inline asm support in LLVM:
>> 1. You just support all the constraints and pastes
>> inline-asm contents
>> as-is. That's why its still allowed to use names like
>> "some_instr".
>> 2. You may expand inline-asm strings set, or in another
>> words just parse
>> it onto set of instructions. In this case you have to
>> implement
>> TargetLowering::__ExpandInlineAsm method.
>> I'd want to start it on this week though...
>>
>> But first we have to get avr-libc compilable (perhpas I
>> read you
>> thoughts ;-) )
>>
>> Relative to memory constrains. I implemented initial version
>> it can
>> catch simplest cases (from test-case):
>>
>> @a = internal global i16 0, align 4
>> @b = internal global i16 0, align 4
>> define void @mem() {
>> ;CHECK: some_instr Z, Y
>> call void asm "some_instr $0, $1", "=*Q,=*Q"(i16* @a,
>> i16* @b)
>> ret void
>> }
>>
>> The patch is attached.
>>
>> Its in my todo yet, to handle local variables. They could be
>> emitted as
>> Y+q expression. Hope to present this support tomorrow. So if
>> 'a' and 'b'
>> from example above would be local we could get "some_instr
>> Y, Y+2"
>>
>> -Stepan.
>>
>>
>>
>>
>>
>
|
