Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly. Mostly just a stub.
|
From: Borja F. <bor...@gm...> - 2013-06-27 17:55:37
|
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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
|
