Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly. Mostly just a stub.
|
From: Borja F. <bor...@gm...> - 2013-06-27 11:34:26
|
When you answer the 2 questions in my previous email :)
2013/6/27 Stepan Dyatkovskiy <stp...@na...>
> Hi Borja,
> So, can I commit that memory constraint patch?
>
>
> -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.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
|
