Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly. Mostly just a stub.
|
From: Borja F. <bor...@gm...> - 2013-06-27 18:47:49
|
btw, if this is now feature complete you can commit it.
2013/6/27 Borja Ferrer <bor...@gm...>
> No, that code is a personal modification of your examples. If you aren't
> getting the correct output from clang that's because you probably didn't
> apply a patch i commited last week for clang in our SVN.
> The assertion you're getting looks reasonable, it's an old friend of mine.
> The reason is that if Y is being reserved as the frame pointer, you cant
> have an instruction that uses 2 registers when only Z is available. I
> wouldn't mind too much about it.
>
> Now, my 2nd question:
>
> Is there anything else that needs to be covered for the memory constraint?
>
>
> 2013/6/27 Stepan Dyatkovskiy <stp...@na...>
>
>> This one looks good. Though ./llc emits "run out of registers allocation.
>> I'll look at it. Is that from avr-libc?
>> -Stepan.
>> Borja Ferrer wrote:
>>
>>> Yes, and then I replied the following:
>>>
>>> For this C code:
>>>
>>> char delay_count;
>>> char aaa;
>>> uint8_t delay(unsigned char p)
>>> {
>>> uint8_t cnt;
>>> asm volatile (
>>> "inst %0, %1" "\n\t"
>>> : "=Q" (delay_count)
>>> : "Q" (aaa));
>>> return cnt;
>>> }
>>>
>>> Clang produces:
>>>
>>> define i8 @delay(i8 %p) #0 {
>>> entry:
>>> tail call void asm sideeffect "inst $0, $1\0A\09", "=*Q,*Q"(i8*
>>> @delay_count, i8* @aaa) #2, !srcloc !4
>>> ret i8 undef
>>> }
>>>
>>> notice the *Q constraints, so is there anything wrong in there?
>>>
>>> Is there anything else that needs to be covered for the memory
>>> constraint?
>>>
>>>
>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na... <mailto:
>>> stp...@na...>>
>>>
>>>
>>> Hi Borja,
>>>
>>> > Stepan, reply in this thread to my 2 questions again if the email
>>> got lost.
>>>
>>> My prev. reply:
>>>
>>>
>>> > 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
>>>
>>> Borja Ferrer wrote:
>>>
>>> Stepan, reply in this thread to my 2 questions again if the
>>> email got lost.
>>>
>>>
>>> 2013/6/27 Borja Ferrer <bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm... <mailto:bor...@gm...>**
>>> >__>
>>>
>>>
>>> No, your last email only says : "So, can I commit that
>>> memory
>>> constraint patch?"
>>>
>>>
>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>>> <mailto:stp...@na...>
>>> <mailto:stp...@na... <mailto:stp...@na...>>>
>>>
>>>
>>>
>>> Hm... Didn't you get my previous mail? If not, I think,
>>> I have
>>> to change my mail box.
>>>
>>> -Stepan
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: [avr-llvm-devel] Inline assembly. Mostly
>>> just a stub.
>>> Date: Tue, 25 Jun 2013 18:30:46 +0400
>>> From: Stepan Dyatkovskiy <stp...@na...
>>> <mailto:stp...@na...>
>>> <mailto:stp...@na... <mailto:stp...@na...>>>
>>> To: Borja Ferrer <bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>__>
>>> CC: avr-llvm <avr-llvm-devel@lists.__source**
>>> __forge.net <http://source__forge.net>
>>> <http://sourceforge.net>
>>> <mailto:avr-llvm-devel@lists._**_sourceforge.net
>>>
>>> <mailto:avr-llvm-devel@lists.**sourceforge.net<avr...@li...>>>>,
>>> John Myers
>>> <ato...@gm...
>>> <mailto:atomicdog.jwm@gmail.**com <ato...@gm...>>
>>> <mailto:atomicdog.jwm@gmail.__**com <mailto:atomicdog.jwm@gmail.
>>> **com <ato...@gm...>>>>
>>>
>>>
>>> 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...>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...>> <mailto:stp...@na...
>>> <mailto:stp...@na...>
>>>
>>> <mailto: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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
|
