Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly. Mostly just a stub.
|
From: Stepan D. <stp...@na...> - 2013-06-28 18:44:25
|
Hi Borja.
This is almost the final multibyte constraint patch. Tests are not
created yet.
Currently I have issue with 64 bit values. Even if I pass them as inline
asm operands, llvm still truncates them to i32.
What works:
long a; // 32 bit
void f() {
asm("instr %A0 %B0 %C0 %D0": : "r"(a));
}
What doesn't work:
long long a; // 64 bit
void f() {
asm("instr %A0 %B0 %E0": : "r"(a));
}
The last one fires assertion since llvm allocates registers for the
first 32 bits only.
-Stepan.
Borja Ferrer wrote:
> Yes fine
>
> El jueves, 27 de junio de 2013, Stepan Dyatkovskiy escribió:
>
> 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://source__forge.net>
> <http://source <http://sourceforge.net>
>
|
