Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly. Mostly just a stub.
|
From: Stepan D. <stp...@na...> - 2013-06-27 19:03:12
|
OK. Will do.
Currently there is a patch with memory constraint and draft multibyte
constraint (supports only A and B). To be clean under multibyte
constraints I mean something like this:
asm volatile("mov __tmp_reg__, %A0" "\n\t"
"mov %A0, %B0" "\n\t"
"mov %B0, __tmp_reg__" "\n\t"
: "=r" (value)
: "0" (value)
);
-Stepan.
Borja Ferrer wrote:
> btw, if this is now feature complete you can commit it.
>
>
> 2013/6/27 Borja Ferrer <bor...@gm...
> <mailto: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...
> <mailto: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...> <mailto: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...>>
> <mailto: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...>>
> <mailto: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...>>
> <mailto: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...>>
> <mailto: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.
> <mailto:avr-llvm-devel@lists.>____sourceforge.net
> <http://sourceforge.net>
>
> <mailto:avr-llvm-devel@lists.__sourceforge.net
> <mailto:avr...@li...>>>>, John Myers
> <ato...@gm...
> <mailto:ato...@gm...>
> <mailto:atomicdog.jwm@gmail.__com
> <mailto:ato...@gm...>>
> <mailto:atomicdog.jwm@gmail.
> <mailto:atomicdog.jwm@gmail.>____com
> <mailto:atomicdog.jwm@gmail.__com
> <mailto: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...>>> <mailto: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.
>
>
>
>
>
>
>
>
>
>
>
>
>
|
