Menu
▾
▴
avr-llvm-devel — Developers mailing list.
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(26) |
Dec
(15) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(14) |
Oct
(16) |
Nov
(36) |
Dec
(3) |
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(17) |
May
(9) |
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(4) |
| 2012 |
Jan
(22) |
Feb
(12) |
Mar
(39) |
Apr
(31) |
May
(42) |
Jun
(35) |
Jul
(32) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
(9) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(121) |
Jul
(61) |
Aug
(7) |
Sep
(8) |
Oct
(6) |
Nov
|
Dec
(1) |
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Borja F. <bor...@gm...> - 2013-06-27 17:36:59
|
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...>
> 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...>**>
>>
>>
>> No, your last email only says : "So, can I commit that memory
>> constraint patch?"
>>
>>
>> 2013/6/27 Stepan Dyatkovskiy <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...>>
>> To: Borja Ferrer <bor...@gm...
>> <mailto:bor...@gm...>**>
>> CC: avr-llvm <avr-llvm-devel@lists.__source**forge.net<http://sourceforge.net>
>> <mailto:avr-llvm-devel@lists.**sourceforge.net<avr...@li...>>>,
>> John Myers
>> <ato...@gm... <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...>>>
>>
>> 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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-27 17:21:21
|
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...>>
>
> No, your last email only says : "So, can I commit that memory
> constraint patch?"
>
>
> 2013/6/27 Stepan Dyatkovskiy <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...>>
> To: Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>>
> CC: avr-llvm <avr-llvm-devel@lists.__sourceforge.net
> <mailto:avr...@li...>>, John Myers
> <ato...@gm... <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...>>>
>
> 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.
>
>
>
>
>
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-27 14:35:19
|
Stepan, reply in this thread to my 2 questions again if the email got lost. 2013/6/27 Borja Ferrer <bor...@gm...> > No, your last email only says : "So, can I commit that memory constraint > patch?" > > > 2013/6/27 Stepan Dyatkovskiy <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...> >> To: Borja Ferrer <bor...@gm...> >> CC: avr-llvm <avr-llvm-devel@lists.**sourceforge.net<avr...@li...>>, >> John Myers <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...>> >>> >>> 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. >>> >>> >>> >>> >>> >>> >> > |
|
From: Stepan D. <stp...@na...> - 2013-06-27 13:35:07
|
BTW, for X86 target and memory constraint I got the same as for ARM:
call void asm "instr $0", "=*m,~{dirflag},~{fpsr},~{flags}"(i32* @a) #1,
!srcloc !0
It just uses 'm' instead of 'Q'. Note it also contains '*' before 'm'.
-Stepan.
Stepan Dyatkovskiy wrote:
> Agh!! MY grammar: Subject: One more differencE in clang. Would you fix
> it in your reply please.
> Thanks.
> -Stepan.
>
> Stepan Dyatkovskiy wrote:
>> Hi guys.
>>
>> Today I went through whole AVR-Libc Inline Assembler Cookbook chapter.
>> I have checked all examples with two commands:
>> 1. clang -S -o - -emit-llvm example.c
>> 2. avr-clang -S -o - -emit-llvm example.c
>>
>> I've found two difference:
>>
>> 1. As I mentioned before difference for memory constraint.
>> For string "asm("instr %0": "=Q"(a):)"
>>
>> clang emits:
>> %0 = call i32 asm "instr $0", "=Q,~{dirflag},~{fpsr},~{flags}"()
>>
>> arm-linux-gnueabi emits:
>> call void asm "instr $0", "=*Q"(i32* @a) #1, !srcloc !0
>>
>> avr-clang:
>> %0 = call i16 asm "instr $0", "=Q"()
>>
>> I'll try to use current syntax here. Though ARM syntax is working well
>> now, but I din't find explanation of =*Q sequence yet.
>>
>> 2. asm names.
>>
>> // example.c:
>> extern long Calc(void) asm ("CALCULATE");
>> void f() { Calc(); }
>>
>> clang emits:
>> %call = call i64 @CALCULATE()
>> ...
>> declare i64 @CALCULATE()
>>
>> avr-clang emits:
>> %call = call i32 @"\01CALCULATE"()
>> ...
>> declare i32 @"\01CALCULATE"()
>>
>> Does somebody know what \01 is used for here?
>>
>> -Stepan
>>
>> ------------------------------------------------------------------------------
>>
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> avr-llvm-devel mailing list
>> avr...@li...
>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-27 11:47:14
|
No, your last email only says : "So, can I commit that memory constraint patch?" 2013/6/27 Stepan Dyatkovskiy <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...> > To: Borja Ferrer <bor...@gm...> > CC: avr-llvm <avr-llvm-devel@lists.**sourceforge.net<avr...@li...>>, > John Myers <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... >> >> >> >> 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. >> >> >> >> >> >> > |
|
From: Stepan D. <stp...@na...> - 2013-06-27 11:43:52
|
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...>
To: Borja Ferrer <bor...@gm...>
CC: avr-llvm <avr...@li...>, John Myers
<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...>>
>
> 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.
>
>
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-27 11:34:26
|
When you answer the 2 questions in my previous email :)
2013/6/27 Stepan Dyatkovskiy <stp...@na...>
> Hi Borja,
> So, can I commit that memory constraint patch?
>
>
> -Stepan.
>
> Stepan Dyatkovskiy wrote:
>
>> 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...>>
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-27 10:34:52
|
Agh!! MY grammar: Subject: One more differencE in clang. Would you fix
it in your reply please.
Thanks.
-Stepan.
Stepan Dyatkovskiy wrote:
> Hi guys.
>
> Today I went through whole AVR-Libc Inline Assembler Cookbook chapter.
> I have checked all examples with two commands:
> 1. clang -S -o - -emit-llvm example.c
> 2. avr-clang -S -o - -emit-llvm example.c
>
> I've found two difference:
>
> 1. As I mentioned before difference for memory constraint.
> For string "asm("instr %0": "=Q"(a):)"
>
> clang emits:
> %0 = call i32 asm "instr $0", "=Q,~{dirflag},~{fpsr},~{flags}"()
>
> arm-linux-gnueabi emits:
> call void asm "instr $0", "=*Q"(i32* @a) #1, !srcloc !0
>
> avr-clang:
> %0 = call i16 asm "instr $0", "=Q"()
>
> I'll try to use current syntax here. Though ARM syntax is working well
> now, but I din't find explanation of =*Q sequence yet.
>
> 2. asm names.
>
> // example.c:
> extern long Calc(void) asm ("CALCULATE");
> void f() { Calc(); }
>
> clang emits:
> %call = call i64 @CALCULATE()
> ...
> declare i64 @CALCULATE()
>
> avr-clang emits:
> %call = call i32 @"\01CALCULATE"()
> ...
> declare i32 @"\01CALCULATE"()
>
> Does somebody know what \01 is used for here?
>
> -Stepan
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-27 10:33:31
|
Hi guys.
Today I went through whole AVR-Libc Inline Assembler Cookbook chapter.
I have checked all examples with two commands:
1. clang -S -o - -emit-llvm example.c
2. avr-clang -S -o - -emit-llvm example.c
I've found two difference:
1. As I mentioned before difference for memory constraint.
For string "asm("instr %0": "=Q"(a):)"
clang emits:
%0 = call i32 asm "instr $0", "=Q,~{dirflag},~{fpsr},~{flags}"()
arm-linux-gnueabi emits:
call void asm "instr $0", "=*Q"(i32* @a) #1, !srcloc !0
avr-clang:
%0 = call i16 asm "instr $0", "=Q"()
I'll try to use current syntax here. Though ARM syntax is working well
now, but I din't find explanation of =*Q sequence yet.
2. asm names.
// example.c:
extern long Calc(void) asm ("CALCULATE");
void f() { Calc(); }
clang emits:
%call = call i64 @CALCULATE()
...
declare i64 @CALCULATE()
avr-clang emits:
%call = call i32 @"\01CALCULATE"()
...
declare i32 @"\01CALCULATE"()
Does somebody know what \01 is used for here?
-Stepan
|
|
From: Stepan D. <stp...@na...> - 2013-06-27 08:09:47
|
Hi Borja,
So, can I commit that memory constraint patch?
-Stepan.
Stepan Dyatkovskiy wrote:
> 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...>>
>>
>> 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.
>>
>>
>>
>>
>>
>
|
|
From: Rick M. <rm...@la...> - 2013-06-25 19:44:18
|
On Jun 25, 2013, at 07:33 , Stepan Dyatkovskiy <stp...@na...> wrote: > And... I mentioned Rick Mann, not John, since Rick said he would like to help us with frontend. My fault. Hi, what? I'm sorry, I think I missed an email. As much as I'd like to work on this, I'm so incredibly swamped at work (Jul 8 deadline followed by intensive QA period), I'm afraid I won't be much use. Plus, you guys are clearly much more capable with LLVM than I am. You're making incredible progress. -- Rick |
|
From: Borja F. <bor...@gm...> - 2013-06-25 14:51:20
|
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/25 Stepan Dyatkovskiy <stp...@na...>
> And... I mentioned Rick Mann, not John, since Rick said he would like to
> help us with frontend. My fault.
>
>
> -Stepan.
>
> Stepan Dyatkovskiy wrote:
>
>> 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...>>
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-25 14:33:53
|
And... I mentioned Rick Mann, not John, since Rick said he would like to
help us with frontend. My fault.
-Stepan.
Stepan Dyatkovskiy wrote:
> 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...>>
>>
>> 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.
>>
>>
>>
>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-25 14:31:00
|
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...>>
>
> 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.
>
>
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-25 14:22:24
|
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.
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.
Ok tests look good, looking at what you covered is there anything else that
needs to be implemented for this constraint?
What's wrong with clang? I fixed clang inline asm support back on friday,
so is there anything else that is broken?
2013/6/25 Stepan Dyatkovskiy <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.
>>>
>>>
>>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-25 12:55:31
|
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.
>>
>>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-24 23:43:18
|
Hello Stepan,
Heh well, the first step on being able to compile avr-libc is to add full
support for inline asm. Once that is finished we can then look at other
places that may still have problems.
The approach you're taking here looks sort of hacky :) but since i dont
have a deep understanding on inline asm i cant think of other alternatives.
I've been trying some code in gcc to see how this Q constraint works but i
wasnt able to compile it, what's wrong in here?
static char var;
char foo() {
char ret;
asm("ld %0, %1": "=r" (ret) : "Q" (var));
return ret;
}
I expected this to work.
Ok, having access to local vars using the Y+q addressing mode is important
since most of them will be in frame indexes.
I've noticed in your patch that you're checking in some places for the 'm'
constraint instead of Q, i know you copied it from the arm backend, but be
careful there in case things dont work as expected.
One last thing, I dont like not allowing Y and Z being inflated. This has
brought many problems in the past and blocks big size reduction
optimizations, disabling this for this inline asm feature is a very
expensive price that we can't pay. Hope this doesnt present any real issues
for you.
2013/6/24 Stepan Dyatkovskiy <stp...@na...>
> 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.
>>
>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-24 18:19:53
|
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.
>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-24 18:19:16
|
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.
|
|
From: Borja F. <bor...@gm...> - 2013-06-23 00:46:35
|
Ok I understand it now. I will check what other backends do, but what you proposed seems reasonable. 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. 2013/6/22 Stepan Dyatkovskiy <stp...@na...> > So I suppose, I need analyze Op in SelectInlineAsmMemoryOperand, > then create virtual reg of PTRDISPREGS class and use it. > > -Stepan. > > Stepan Dyatkovskiy wrote: > >> Hi Borja, >> >> Borja Ferrer wrote: >> >>> Resending the email to the list without any previous emails: >>> >>> Hello Stepan, >>> >>> 1) This should be fixed now with my last commit. >>> 2) I dont really understand what you mean. Can you expand a bit more >>> here? >>> >> >> Currently for line: >> >> call void asm "some_instr $0", "=*Q"(i16* @b) >> >> It does emit: >> >> ldi r24, lo8(b) >> ldi r25, hi8(b) >> ;APP >> some_instr [r24] >> >> While it shuold emit Y+q instead of r24 e.g.: >> >> ldi YL , lo8(b) >> ldi YH , hi8(b) >> ;APP >> some_instr Y+1 >> >> -Stepan >> >> ------------------------------**------------------------------** >> ------------------ >> >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-**dev2dev<http://p.sf.net/sfu/windows-dev2dev> >> ______________________________**_________________ >> avr-llvm-devel mailing list >> avr-llvm-devel@lists.**sourceforge.net<avr...@li...> >> https://lists.sourceforge.net/**lists/listinfo/avr-llvm-devel<https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel> >> >> > |
|
From: Stepan D. <stp...@na...> - 2013-06-22 19:32:53
|
So I suppose, I need analyze Op in SelectInlineAsmMemoryOperand, then create virtual reg of PTRDISPREGS class and use it. -Stepan. Stepan Dyatkovskiy wrote: > Hi Borja, > > Borja Ferrer wrote: >> Resending the email to the list without any previous emails: >> >> Hello Stepan, >> >> 1) This should be fixed now with my last commit. >> 2) I dont really understand what you mean. Can you expand a bit more here? > > Currently for line: > > call void asm "some_instr $0", "=*Q"(i16* @b) > > It does emit: > > ldi r24, lo8(b) > ldi r25, hi8(b) > ;APP > some_instr [r24] > > While it shuold emit Y+q instead of r24 e.g.: > > ldi YL , lo8(b) > ldi YH , hi8(b) > ;APP > some_instr Y+1 > > -Stepan > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > |
|
From: Stepan D. <stp...@na...> - 2013-06-22 19:19:29
|
Hi Borja,
Borja Ferrer wrote:
> Resending the email to the list without any previous emails:
>
> Hello Stepan,
>
> 1) This should be fixed now with my last commit.
> 2) I dont really understand what you mean. Can you expand a bit more here?
Currently for line:
call void asm "some_instr $0", "=*Q"(i16* @b)
It does emit:
ldi r24, lo8(b)
ldi r25, hi8(b)
;APP
some_instr [r24]
While it shuold emit Y+q instead of r24 e.g.:
ldi YL , lo8(b)
ldi YH , hi8(b)
;APP
some_instr Y+1
-Stepan
|
|
From: Borja F. <bor...@gm...> - 2013-06-22 11:39:47
|
Resending the email to the list without any previous emails: Hello Stepan, 1) This should be fixed now with my last commit. 2) I dont really understand what you mean. Can you expand a bit more here? |
|
From: Stepan D. <stp...@na...> - 2013-06-21 17:49:40
|
Hi all,
I've made the skeleton for memory constraint. Though, currently its not
clean to me how to force use of PTRDISPREGS class.
Currently two issues are opened here:
1. Clang front-end:
For input:
static int b;
void f()
{
int a;
asm("instr %0": "=Q"(b):);
}
it should produce (with -S -emit-llvm flags):
call void asm "some_instr $0", "=*Q"(i16* @b)
While now it produces:
%0 = call i16 asm "instr $0", "=Q"()
2. Currently it uses GPR8 pairs class, I'm not sure where it is better
to force PTRDISPREGS. So, currently for .ll line:
; some stuff above
call void asm "some_instr $0", "=*Q"(i16* @b)
; some stuff below
I have llc output:
.file "inline-asm-mem.ll"
.text
.globl memory
.align 2
.type memory,@function
memory: ; @memory
; BB#0:
ldi r24, lo8(b)
ldi r25, hi8(b)
;APP
some_instr [r24]
;NO_APP
ret
.Ltmp0:
.size memory, .Ltmp0-memory
.type b,@object ; @b
.local b
.comm b,2,4
Current state is applied as patch.
-Stepan.
Borja Ferrer wrote:
> 1) Ok I understand now your point. It's a valid hack for now.
> 2) I see, I've done some tests and it works as expected so no more worries.
>
> I've been testing some complex inline asm from avr libc and found the
> following things:
> 1) I was able to trigger the assertion in getRegForInlineAsmConstraint,
> I havent investigated more, but it's something that needs to be looked at.
> 2) there are some constraints to work with multi byte values (A0, B0,
> C0, etc) that dont work at all, they produce wrong code. I guess this is
> the next thing that should be implemented.
> 3) Likewise from 2) the %a0 constraint for the base pointer regs wont
> work either.
>
> One more thing, remember to commit the test cases when they're ready.
>
>
> 2013/6/20 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>>
>
> Hello Borja,
>
>
> > 1) for the M constraint you expand the type to MVT::i16 in case the
>
> value is negative. I dont understand the need to do this.
>
> By default AsmWriter treats constants as signed values. So "i8 255"
> would be printed as "i8 -1". But I'm not sure that avr-as would
> interpret this as "*i8* -1" (I even definitely sure it fails some
> code). So I'v made it i16; doing that, we can be sure that values in
> range 0..255 would be printed as unsigned.
> May be it is kind of hack, though on the first stage I'd just make
> things working...
>
>
> 2) did you manage to understand how the G constraint works? I
> see you
> return a 0 MVT::i8 constant, but floats are 32 bits so how does this
> really work.
>
> IMHO, kind of stupid constraint. avr-gcc doesn't eat .c inline asm
> string like below:
>
> 'asm("instr %0"::"G"(0.1) );'
>
> avr-gcc exits with error: impossible constraint in ‘asm’
>
> while 'asm("instr %0"::"G"(0.0) )' works fine.
>
> 'asm("instr %0"::"G"() );' doesn't work either.
>
> So '"G"(0.0)' is the only correct case.
>
> I set it to i8, since we just need convert it to zero. I suppose for
> avr-as it doesn't matter which kind of zero would be presented (0,
> 0x0 or 0.000). E.g. avr-gcc prints 0x0.
>
> -Stepan.
>
> P.S.: Just as playground code:
> // file: test.c
> // cmd: avr-gcc test.c -S -o -
> void f() {
> int a,b,c,d;
> asm("instr %0"::"G"(0.0) );
> }
>
>
>
>
>
> 2013/6/18 Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>
> <mailto:bor...@gm... <mailto:bor...@gm...>>__>
>
> Sure Stepan, go ahead. I can do any post commit cleanups
> afterwards.
>
>
> 2013/6/17 John Myers <ato...@gm...
> <mailto:ato...@gm...>
> <mailto:atomicdog.jwm@gmail.__com
> <mailto:ato...@gm...>>>
>
>
> You should have commit access.
>
>
> On Mon, Jun 17, 2013 at 1:35 PM, Stepan Dyatkovskiy
> <stp...@na... <mailto:stp...@na...>
> <mailto:stp...@na... <mailto:stp...@na...>>> wrote:
>
> Hi Borja,
> 2.1:
> You're right. Will return C_Register.
> About Q, I'd want to learn a bit more before it
> would be
> implemented. Perhaps there is nothing special, but
> I'd want
> to check.
> 2.2. Yes, we can return cw_constant. I had used ARM
> template
> :-) They just had set it as cw_other :-)
> 3. avr-llvm has appeared in "My Projects" in source
> forge
> menu. Does it mean I have permissions already? Can
> I do test
> commit (one more \n in README)?
> 4. I propose to commit everything (with fixes you
> proposed)
> to avoid growing snow ball patch ;-)
> --
> Truly yours,
> Stepan Dyatkovskiy
> 17.06.2013, 22:50, "Borja Ferrer"
> <bor...@gm... <mailto:bor...@gm...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>__>:
>
> Ok thanks for the fixes, more things:
>
> 2.1) AVRTargetLowering::__getConstraintType:
> Looking at
> other backends, I think the x, y, z, t
> constraints should
> return C_Register instead of C_RegisterClass
> since these
> are used for specific regs inside a regclass.
> Probably the
> same for the q one. What do you think?
>
> 2.2) Ok, so you've given the largest weight to
> the bigger
> regclasses d, r, l and then for the other reg
> constraints
> the smaller weight, I agree then.
> Now, for the constant constraints you should return
> CW_Constant instead, other backends first check
> that the
> imm val is in range and if it is then set it to
> that
> value, this is taken from the x86 one:
> case 'K':
> if (ConstantInt *C =
> dyn_cast<ConstantInt>(__CallOperandVal)) {
> if ((C->getSExtValue() >= -0x80) &&
> (C->getSExtValue() <= 0x7f))
> weight = CW_Constant;
> }
> break;
> Finally for Q we should return CW_Memory no?
>
> 2.3) In getRegForInlineAsmConstraint, if this
> inline asm
> stuff is run after type legalization you could
> turn that
> type checking at the top of the function into
> an assert()
> comment: Upper register r16..r32. <<-- typo
> registerS and r32
>
> John or Eric, please give Stepan commit
> permissions.
>
>
> 2013/6/17 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na...
> <mailto:stp...@na...>>>
>
>
> Hello Borja,
>
>
> ok here we go:
>
> 1) in AVRRegisterInfo.td: im ok with
> the lGPR8
> regclass since we dont
> have it yet and i guess it's needed for
> the l
> constraint, but rename it
> to GPR8lo. The hGPR8 regclass comment
> says lower
> registers, so typo
> there, but anyways can't you use the
> LD8 regclass?
> Rename simplehGPR8 to
> LD8lo, we'll need it in the future for
> some MUL
> instructions.
>
> Everything here were fixed as you mentioned.
>
>
>
> 2) in AVRISelLowering.cpp: for the t,
> x, y, z
> shouldn't we return
> C_Register? Probably for b aswell.
> 2.1) in getSingleConstraintMatchWeight
> can you
> clarify me what's the
> diff between CW_SpecificReg and
> CW_Register.
> Shouldn't the G constraint
> be a Constant? Same for the other
> constraints?
>
> All this stuff with weights is due to
> support of
> multiple constraints. For some operands you
> may set
> *the set* of constraints, e.g. 'mr': get
> either memory
> of register. In that case we're use
> weights. What
> should we select for 'bx' constraint for
> example? One
> of y,z or x? So, currently llvm gets
> register first
> from class with bigger weight. Since
> CW_SpecificReg <
> CW_Register it will select one of y,z.
>
> For more information see implementation of
>
> "TargetLowering::____getMultipleConstraintMatchWeig____ht"
> and "TargetLowering::____ParseConstraints".
>
>
> 'G' shouldn't be CW_Register, of course,
> that was my
> typo. I've fixed it, now it as all other
> constants
> just a CW_Default.
>
>
> 2.2) in getRegForInlineAsmConstraint
> fixup the
> regclasses per point (1).
> for w you could use the IWREGS
> regclass, the docs
> say they are regpairs,
> not 8 bit regs as you declared in the
> .td file.
>
> That was also fixed.
>
> -Stepan.
>
>
> The rest looks great.
>
>
> 2013/6/14 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...>>__>__>
>
>
> Going to review the patch now.
>
> No, there is no test for allocation
> order, I
> don't know a good way
> of testing that. If you want you
> can replace
> the register list by
> several sequences.
>
>
> 2013/6/14 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,
> All constraints are supported now.
> The new patch is attached.
>
> -- Added support for all documented
> constraints.
> -- Fixed tests as you mentioned.
>
> Relative to GPR8,
> Do we have some tests that check
> allocation order? If so, all of
> them were passed :-)
>
> Though I can use the explicit
> enumeration
> way you're currently
> using...
>
> -Stepan.
>
> Borja Ferrer wrote:
>
> Ok, there are some small
> style issues
> but i will fix them
> after you can
> commit (braces in
> AVRAsmPrinter::______PrintAsmOperand),
>
>
> afterwards you may
> check them for future
> reference.
>
> About the GPR8 replacement,
> I'm not
> sure now, but will it
> change the
> register allocation order
> using the
> "sequence" set
> instruction? This was
> changed some time ago so I dont
> remember what was the
> new...@na... <mailto:new...@na...>
>
> <mailto:stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na...
> <mailto:stp...@na...>>>>>>
>
>
>
> Hi all,
> I'll use this
> reference for
> implementation, right?
> http://savannah.nongnu.org/________download/avr-libc/avr-libc-________user-manual-1.8.0.pdf.__bz2
> <http://savannah.nongnu.org/______download/avr-libc/avr-libc-______user-manual-1.8.0.pdf.bz2>
>
> <http://savannah.nongnu.org/______download/avr-libc/avr-libc-______user-manual-1.8.0.pdf.bz2
> <http://savannah.nongnu.org/____download/avr-libc/avr-libc-____user-manual-1.8.0.pdf.bz2>>
>
>
>
> <http://savannah.nongnu.org/______download/avr-libc/avr-libc-______user-manual-1.8.0.pdf.bz2
> <http://savannah.nongnu.org/____download/avr-libc/avr-libc-____user-manual-1.8.0.pdf.bz2>
>
> <http://savannah.nongnu.org/____download/avr-libc/avr-libc-____user-manual-1.8.0.pdf.bz2
> <http://savannah.nongnu.org/__download/avr-libc/avr-libc-__user-manual-1.8.0.pdf.bz2>>>
>
>
>
>
>
> <http://savannah.nongnu.org/______download/avr-libc/avr-libc-______user-manual-1.8.0.pdf.bz2
> <http://savannah.nongnu.org/____download/avr-libc/avr-libc-____user-manual-1.8.0.pdf.bz2>
>
> <http://savannah.nongnu.org/____download/avr-libc/avr-libc-____user-manual-1.8.0.pdf.bz2
> <http://savannah.nongnu.org/__download/avr-libc/avr-libc-__user-manual-1.8.0.pdf.bz2>>
>
>
> <http://savannah.nongnu.org/____download/avr-libc/avr-libc-____user-manual-1.8.0.pdf.bz2
> <http://savannah.nongnu.org/__download/avr-libc/avr-libc-__user-manual-1.8.0.pdf.bz2>
>
> <http://savannah.nongnu.org/__download/avr-libc/avr-libc-__user-manual-1.8.0.pdf.bz2
> <http://savannah.nongnu.org/download/avr-libc/avr-libc-user-manual-1.8.0.pdf.bz2>>>>
>
> -Stepan.
>
> Stepan
> Dyatkovskiy
> wrote:
> > Ops.
> Forget to
> apply patch itself...
> >
> > -Stepan.
> >
> > Stepan
> Dyatkovskiy wrote:
> >> Hi
> all. That's a
> Thursday patch with
> inline asm.
> Currently
> the only
> >>
> constraint is
> supported: register ('r').
> >>
> >> -Stepan.
> >>
> >>
>
>
>
> ------------------------------________------------------------__--__--__--__------------------
>
>
>
> >>
> >> This
> SF.net
> email is sponsored by Windows:
> >>
> >> Build for
> Windows Store.
> >>
> >>
> http://p.sf.net/sfu/windows-________dev2dev
> <http://p.sf.net/sfu/windows-______dev2dev>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>>
>
>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>>>
>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>
> <http://p.sf.net/sfu/windows-__dev2dev
> <http://p.sf.net/sfu/windows-dev2dev>>>>
> >>
>
>
> _______________________________________________________
> >>
> avr-llvm-devel
> mailing list
> >>
> avr-llvm-devel@lists.__
> <mailto:avr-llvm-devel@lists.
> <mailto:avr-llvm-devel@lists.>____>sourcef____orge.net
> <http://sourcef____orge.net> <http://sourcef__orge.net/>
> <http://sourceforge.net
> <http://sourceforge.net/>>
>
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.>______sourceforge.net
> <http://sourceforge.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...>>>>
>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>>.
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>>.__>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net/>
> <http://sourceforge.net
> <http://sourceforge.net/>>
>
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.>______sourceforge.net
> <http://sourceforge.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...>>>>>
>
> >>
> https://lists.sourceforge.net/________lists/listinfo/avr-llvm-______devel
> <https://lists.sourceforge.net/______lists/listinfo/avr-llvm-____devel>
>
> <https://lists.sourceforge.__net/____lists/listinfo/avr-__llvm-__devel
> <https://lists.sourceforge.net/____lists/listinfo/avr-llvm-__devel>>
>
>
> <https://lists.sourceforge.____net/__lists/listinfo/avr-llvm-____devel
>
> <https://lists.sourceforge.__net/__lists/listinfo/avr-llvm-__devel
> <https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel>>>
>
> <https://lists.sourceforge.
>
> <https://lists.sourceforge./>______net/lists/listinfo/avr-__llvm-____devel
>
>
> <https://lists.sourceforge.____net/lists/listinfo/avr-llvm-____devel
>
> <https://lists.sourceforge.__net/lists/listinfo/avr-llvm-__devel
> <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel>>>>
> >>
> >
> >
> >
> >
>
>
>
>
> ------------------------------________------------------------__--__--__--__------------------
>
>
>
> > This
> SF.net email
> is sponsored by Windows:
> >
> > Build
> for Windows
> Store.
> >
> >
> http://p.sf.net/sfu/windows-________dev2dev
> <http://p.sf.net/sfu/windows-______dev2dev>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>>
>
>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>>>
>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>
> <http://p.sf.net/sfu/windows-__dev2dev
> <http://p.sf.net/sfu/windows-dev2dev>>>>
> >
> >
> >
> >
>
>
> _______________________________________________________
> >
> avr-llvm-devel
> mailing list
> >
> avr-llvm-devel@lists.__
> <mailto:avr-llvm-devel@lists.
> <mailto:avr-llvm-devel@lists.>____>sourcef____orge.net
> <http://sourcef____orge.net> <http://sourcef__orge.net/>
> <http://sourceforge.net
> <http://sourceforge.net/>>
>
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.>______sourceforge.net
> <http://sourceforge.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...>>>>
>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>>.
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>>.__>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net/>
> <http://sourceforge.net
> <http://sourceforge.net/>>
>
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.>______sourceforge.net
> <http://sourceforge.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...>>>>>
>
> >
> https://lists.sourceforge.net/________lists/listinfo/avr-llvm-______devel
> <https://lists.sourceforge.net/______lists/listinfo/avr-llvm-____devel>
>
> <https://lists.sourceforge.__net/____lists/listinfo/avr-__llvm-__devel
> <https://lists.sourceforge.net/____lists/listinfo/avr-llvm-__devel>>
>
>
> <https://lists.sourceforge.____net/__lists/listinfo/avr-llvm-____devel
>
> <https://lists.sourceforge.__net/__lists/listinfo/avr-llvm-__devel
> <https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel>>>
>
> <https://lists.sourceforge.
>
> <https://lists.sourceforge./>______net/lists/listinfo/avr-__llvm-____devel
>
>
> <https://lists.sourceforge.____net/lists/listinfo/avr-llvm-____devel
>
> <https://lists.sourceforge.__net/lists/listinfo/avr-llvm-__devel
> <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel>>>>
> >
>
>
>
>
>
>
> ------------------------------________------------------------__--__--__--__------------------
>
>
>
> This
> SF.net email is
> sponsored by Windows:
>
> Build for
> Windows Store.
> http://p.sf.net/sfu/windows-________dev2dev
> <http://p.sf.net/sfu/windows-______dev2dev>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>>
>
>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>>>
>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>
> <http://p.sf.net/sfu/windows-__dev2dev
> <http://p.sf.net/sfu/windows-dev2dev>>>>
>
>
>
> _______________________________________________________
>
> avr-llvm-devel
> mailing list
> avr-llvm-devel@lists.__
>
> <mailto:%C2%A0avr-llvm-devel@__lists.__>sourcef____orge.net
> <http://sourcef____orge.net>
> <http://sourcef__orge.net/>
> <http://sourceforge.net
> <http://sourceforge.net/>>
>
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.>______sourceforge.net
> <http://sourceforge.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...>>>>
>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>>.
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>>.__>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net/>
> <http://sourceforge.net
> <http://sourceforge.net/>>
>
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.>______sourceforge.net
> <http://sourceforge.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...>>>>>
> https://lists.sourceforge.net/________lists/listinfo/avr-llvm-______devel
> <https://lists.sourceforge.net/______lists/listinfo/avr-llvm-____devel>
>
> <https://lists.sourceforge.__net/____lists/listinfo/avr-__llvm-__devel
> <https://lists.sourceforge.net/____lists/listinfo/avr-llvm-__devel>>
>
>
> <https://lists.sourceforge.____net/__lists/listinfo/avr-llvm-____devel
>
> <https://lists.sourceforge.__net/__lists/listinfo/avr-llvm-__devel
> <https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel>>>
>
> <https://lists.sourceforge.
>
> <https://lists.sourceforge./>______net/lists/listinfo/avr-__llvm-____devel
>
>
> <https://lists.sourceforge.____net/lists/listinfo/avr-llvm-____devel
>
> <https://lists.sourceforge.__net/lists/listinfo/avr-llvm-__devel
> <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel>>>>
>
>
>
>
>
>
>
>
>
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-21 00:40:14
|
Sure, commit it if you think it's ready, now it's very important to have test cases when new features are being added. Then when you implement the memory constraint, add a new test case. I've temporarily reverted the assert until we discover why it's failing, there's a FIXME to remind us. 2013/6/20 Stepan Dyatkovskiy <stp...@na...> > Hi Borja, > > > 2) there are some constraints to work with multi byte values (A0, B0, >> C0, etc) that dont work at all, they produce wrong code. I guess this is >> the next thing that should be implemented. >> > OK. Will work at it. > > > One more thing, remember to commit the test cases when they're ready. >> > Agh! Forgot to add it. So you mean to commit it now if they a ready? > > P.S.: Hope will present patch for memory constraint tomorrow. > > -Stepan. > |
14 messages has been excluded from this view by a project administrator.
