Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly. Mostly just a stub.
|
From: Stepan D. <stp...@na...> - 2013-07-01 17:21:39
|
Hi Borja.
1. OK. Will add it.
2.
> movw r30, r24
> adiw r30, 1
Yup, we can replace it with "load r24, Z+1". I'll improve LowerINLINEASM
a bit then.
3. If I'm got right, our main goal now is to get avr-libc compilable?
Whould you tell me would else remained to do with inline-asm?
-Stepan.
Borja Ferrer wrote:
> 1) Yes, an assert could do it. Fixup your patch to only allow A down to
> D constraints.
> 2) This code was compiled with -O3, cant you reproduce it?
>
>
> 2013/6/29 Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>>
>
> Ok more things, I've looked into the 64bit constraints and gcc
> doesnt seem to support them, for this code:
>
> unsigned long long delay(unsigned long long a, unsigned long long b)
>
> {
> uint8_t cnt;
> asm volatile (
> "add %A0, %A1" "\n\t"
> "add %B0, %B1" "\n\t"
> "add %C0, %C1" "\n\t"
> "add %D0, %D1" "\n\t"
> "add %E0, %E1" "\n\t"
> "add %F0, %F1" "\n\t"
> "add %G0, %G1" "\n\t"
> "add %H0, %H1" "\n\t"
> : "=r" (a)
> : "r" (b));
> return a;
> }
>
> gcc produces (ignoring frames):
> movw r18,r10
> movw r20,r12
> movw r22,r14
> movw r24,r16
> /* #APP */
> ; 266 "test.c" 1
> add r10, r18
> add r11, r19
> add r12, r20
> add r13, r21
> add r10, r18
> add r10, r18
> add r10, r18
> add r10, r18
>
> ; 0 "" 2
> /* #NOAPP */
> movw r18,r10
> movw r20,r12
> movw r22,r14
> movw r24,r16
>
> notice how the last 4 add instructions are wrong.
>
>
>
> 2013/6/29 Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>>
>
> Ignore my previous email, it was my fault. Now, for the
> following code:
>
> uint8_t delay(unsigned char *p)
>
> {
> uint8_t cnt=8;
> asm volatile (
> "ld %0, %1" "\n\t"
> : "=r" (cnt)
> : "Q" (p[1]));
> return cnt;
> }
>
> we get:
> movw r30, r24
> adiw r30, 1
> ;APP
> ld r24, Z
>
> ;NO_APP
> ret
>
> Ideally, that adiw should be folded into the load.
>
>
>
> 2013/6/29 Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>>
>
> Stepan I've been testing the memory constraint but im
> getting an assertion for the following code:
>
> uint8_t delay(unsigned char **p)
> {
> uint8_t cnt=8;
> asm volatile (
> "ld %0, %1" "\n\t"
> : "=r" (cnt)
> : "Q" (p[7]));
> return cnt;
> }
>
> What's wrong in here?
>
>
> 2013/6/29 Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>>
>
> 1) Ok then, I will look into it.
> 2) Yes, in theory types should be legalized up to i16
> max, but for some reason i got that assertion triggered,
> i think it was with multibyte inline asm, so this has to
> be solved.
>
>
> 2013/6/28 Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>>
>
> Hello Stepan, I will take a look to your patch
> later, but some questions:
>
> 1) does avr-gcc support 64bit values?
> 2) now that you're working with big data types, does
> it make sense to remove the assert I commented out
> about value types that are different to i8 AND i16?
>
>
>
> 2013/6/28 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...>>
>
> 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...>
> <mailto: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...>
> <mailto: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...>>
> <mailto: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...>>__>
>
> <mailto: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...>>>
>
> <mailto: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...>>>
>
> <mailto: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...>>__>
>
> <mailto: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__forge.net>
>
> <http://source <http://sourceforge.net>
>
>
>
>
>
>
>
>
|
