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: Stepan D. <stp...@na...> - 2013-07-12 13:26:37
|
Hello Borja. Seems I've made things much simpler. Can't understand why I didn't it in beginning. I moved everything into SelectInlineAsmMemoryOperand hook. #1: We don't need 'for' at all. Since it implemented in hook caller. #2: This problem disappeared, see #1. #4: The same. #6: Still not sure about glues. I just tried to keep all chains in proper order. But you rather look at new SelectInlineAsmMemoryOperand. > One last thing, when you run the regression tests, enable locally the > machine verifier to catch any additional errors. To enable it > unconditionally search for the command object (i think it's declared in > codegen/passes.cpp as a cl::opt) and turn it on by default. When you're > doing your own tests you can enable it passing -verify-machineisntrs or > something like that to llc. OK. -Stepan. Borja Ferrer wrote: > Hello Stepan, > > 1) Wow, those are really big conditions xD. You could split them into > single conditions and use continues: > if (cond 1) continue; > if (cond 2) continue; > etc... > > instead of having a huge if() that is quite hard to read. > > 2) Yes I thought about that aswell, that not all constant nodes are asm > flags, but the ARM backend does this, so either they have a bug there or > it's safe? > I prefer if you could move the big condition inside the for() into the > top of the loop, it makes the for() quite unreadable. And adjust there > the i variable as needed for each suboperand as you mentioned before. > > 4) Why do you say they handle everything in the SelectInlineAsm method? > As far as i can see they only handle one specific case, otherwise they > return NULL and let the default behaviour do the work. > > 6) Yes glues are a bit tricky, dont worry about them, I will fix them > when this gets commited. > > One last thing, when you run the regression tests, enable locally the > machine verifier to catch any additional errors. To enable it > unconditionally search for the command object (i think it's declared in > codegen/passes.cpp as a cl::opt) and turn it on by default. When you're > doing your own tests you can enable it passing -verify-machineisntrs or > something like that to llc. > |
|
From: Borja F. <bor...@gm...> - 2013-07-11 16:02:25
|
Hello Stepan, 1) Wow, those are really big conditions xD. You could split them into single conditions and use continues: if (cond 1) continue; if (cond 2) continue; etc... instead of having a huge if() that is quite hard to read. 2) Yes I thought about that aswell, that not all constant nodes are asm flags, but the ARM backend does this, so either they have a bug there or it's safe? I prefer if you could move the big condition inside the for() into the top of the loop, it makes the for() quite unreadable. And adjust there the i variable as needed for each suboperand as you mentioned before. 4) Why do you say they handle everything in the SelectInlineAsm method? As far as i can see they only handle one specific case, otherwise they return NULL and let the default behaviour do the work. 6) Yes glues are a bit tricky, dont worry about them, I will fix them when this gets commited. One last thing, when you run the regression tests, enable locally the machine verifier to catch any additional errors. To enable it unconditionally search for the command object (i think it's declared in codegen/passes.cpp as a cl::opt) and turn it on by default. When you're doing your own tests you can enable it passing -verify-machineisntrs or something like that to llc. |
|
From: Stepan D. <stp...@na...> - 2013-07-11 10:36:45
|
Hello Borja,
> 1) you can reverse some conditions in the loop and use continues to
> reduce identation.
I've joined condition of three if-s, well it reduced code indentation,
though now we got single big if. Though I think its better to deal with
this 'if' instead of big indentations.
> 2) you can add this at the top of the loop
> if (ConstantSDNode *C =
dyn_cast<ConstantSDNode>(N->getOperand(i))) {
> Flag = C->getZExtValue();
> Kind = InlineAsm::getKind(Flag);
> }
> else
> continue;
If would possible if we have guarantee that all ConstantSDNode are
flags, but we haven't. So the problem is that before continue we should:
1. Skip all "sub-operands"
And straight after continue we should (or straight before real loop body):
2. Get flags for new operand
3. Extract NumVals (number of sub-operands or sub-values).
I have moved them into 'for':
2,3 => 'for' condition clause.
1. => 'for' evolution clause.
Finally I got next for pretty outstandard, so be ready :-) :
[code]
for (unsigned i = InlineAsm::Op_FirstOperand, Flags, NumVals;
(i != NumOps) &&
(Flags =
cast<ConstantSDNode>(Node->getOperand(i))->getZExtValue()) &&
(NumVals = InlineAsm::getNumOperandRegisters(Flags)) &&
(++i) /*Skip the ID value.*/;
i += NumVals
)
[/code]
> 3) watch out with placing the asterisk of pointers next to the variable
> not the type and i've seen some double spaces when passing arguments
> after the comma.
Fixed.
> 4) to be consistent with the rest of selectX functions please return a
> NULL when no matching is possible, build a new node when matching
> succeeds and break in the switch above to fall back to default behaviour
> when the result is NULL.
That was fixed too. Though on Select method we still have difference
with ARM implementation. Since they handle everything in SelectInlineAsm
method. Even operands processing.
While we have much less people in our team and have to keep default as
much as possible :-)
> 5) I guess SDLocs can be constructed once with the original node instead
> of constructing lots of differents ones.
I tried to keep same SDLocs as it was in nodes I replaced. Though for
add reg,imm opt I did as you asked.
> 6) I haven't checked this enough but, are we missing any glue operands
> when doing reg copies? Same for the glue operand of the inlneasm node,
> the ARM backend has them.
Glue is kind of dark horse to me. I asked Baldrick what it does. He says
that usually when instruction #1 changes some flag implicitly and
instruction #2 uses this flag (implicitly), you probably want to keep
these instructions "glued".
In inlineasm node I just passed all glue operands as-is without
changing. Do we need some extra glues for 'add reg, imm' opt?
-Stepan.
Borja Ferrer wrote:
> Hello Stepan,
>
> I like this approach better, it feels more general, and indeed doing it
> in ISel is a better place. The SelectAddr stuff it's fine, no need to
> move that new code you added into SelectInlineAsmMemoryOperand.
>
> Some comments about AVRDAGToDAGISel::SelectInlineAsm:
>
> 1) you can reverse some conditions in the loop and use continues to
> reduce identation.
> 2) you can add this at the top of the loop
> if (ConstantSDNode *C = dyn_cast<ConstantSDNode>(N->getOperand(i))) {
> Flag = C->getZExtValue();
> Kind = InlineAsm::getKind(Flag);
> }
> else
> continue;
> to remove: for (; NumVals; --NumVals, ++i) when we need to continue the
> loop.
> I guess this is equivalent but please confirm.
> of course add a AsmNodeOperands.push_back(op); or whatever at the top of
> the loop to not ignore the operands that are skipped.
> 3) watch out with placing the asterisk of pointers next to the variable
> not the type and i've seen some double spaces when passing arguments
> after the comma.
> 4) to be consistent with the rest of selectX functions please return a
> NULL when no matching is possible, build a new node when matching
> succeeds and break in the switch above to fall back to default behaviour
> when the result is NULL.
> 5) I guess SDLocs can be constructed once with the original node instead
> of constructing lots of differents ones.
> 6) I haven't checked this enough but, are we missing any glue operands
> when doing reg copies? Same for the glue operand of the inlneasm node,
> the ARM backend has them.
>
>
>
> 2013/7/10 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>>
>
> Hi Borja,
>
> > About the patch:
> > Is all the code in AVRISelLowering.cpp necesarry? I find it to be
> a very
> > "manual" way of doing this optimization, it feels like not being very
> > general, so please confirm me that this the only way of doing it. Im
> > asking this in case in AVRISelDAGToDAG.cpp you could add some code to
> > match this sort of DAGs with the existing adressing mode matching
> > functions to avoid the code in the other file. Maybe look at what
> other
> > backends do?
> I've compared it with ARM backend today (the only one that does
> something serious with InlineAsm node).
> Well all stuff I did in LowerINLINEASM is implemented in
> SelectInlineAsm, in ARMISelDAGToDAG.
> Well that's true, its not a lowering. I closer to the final stage,
> when you just correct the things and select proper instructions.
> So I did the same: I've moved everything from LowerINLINEASM to
> SelectInlineAsm. The new patch is attached.
>
> Theoretically, we can move everything related to memory constraint
> into single SelectInlineAsm method. But in this case I'll need to
> check all default behaviour that will be overridden. For me it is
> better to have as much default behaviour as possible.
>
> > In AVRISelDAGToDAG.cpp you've removed this line:
> > cast<MemSDNode>(Op)->__getMemoryVT().getSimpleVT();
> > to be:
> > + if (MemSDNode* MemNode = dyn_cast<MemSDNode>(Op))
> > Is this condition always going to be true? the cast above never
> failed
> > for me so in theory the dyn_cast should always be true, making
> the rest
> > of elses there always false.
> If Op is not a MemSDNode it dyn_cast will return false. So MemSDNode
> is load or store node. InlineAsm in our case could play the same
> role too. If you think it is some extra code in SelectAddr I can
> move it to SelectInlineAsmMemoryOperand, though I'll have to
> copypaste something from SelectAddr in this case.
>
> -Stepan.
>
> Borja Ferrer wrote:
>
> Jej no problem, I know you've been busy with some ARM stuff.
>
> Yes let's get this in first, and then we can talk about the
> multibyte stuff.
>
> About the patch:
> Is all the code in AVRISelLowering.cpp necesarry? I find it to
> be a very
> "manual" way of doing this optimization, it feels like not being
> very
> general, so please confirm me that this the only way of doing it. Im
> asking this in case in AVRISelDAGToDAG.cpp you could add some
> code to
> match this sort of DAGs with the existing adressing mode matching
> functions to avoid the code in the other file. Maybe look at
> what other
> backends do?
>
> In AVRISelDAGToDAG.cpp you've removed this line:
> cast<MemSDNode>(Op)->__getMemoryVT().getSimpleVT();
> to be:
> + if (MemSDNode* MemNode = dyn_cast<MemSDNode>(Op))
> Is this condition always going to be true? the cast above never
> failed
> for me so in theory the dyn_cast should always be true, making
> the rest
> of elses there always false.
>
>
>
> 2013/7/9 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>
>
> Hello Borja,
> Sorry for latency, I had to be on dev. meeting.
> I've implemented optimization for memory constraint
> support. The
> patch is in attachment.
>
> P.S.: When I started to work on this opt, I forgot about
> multibyte
> constraints patch is not committed. So I can send it after
> we commit
> this opt.
>
> -Stepan.
>
> Borja Ferrer wrote:
>
> Yes but the first goal now is to have inline asm
> feature complete xD
> Then we can move into other places of the library.
>
> Taking a look at the previous emails this is what needs
> still to
> be done:
> 1) Implement the missed optimization above for the memory
> constraint.
> Also see if you can come with further cases. Remember
> to add a
> test case.
> 2) Implement the stuff in the "C names used in
> assembler code"
> section
> of the avrlibc manual. You mentioned some issues here in a
> previous email.
> 3) Implement the a0, a1, etc... constraints.
>
>
>
> 2013/7/1 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.
> 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...>
> <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...>>__>__>__>
>
>
> 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...>
> <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...>>__>__>__>
>
>
> 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...>
> <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...>>__>__>__>
>
>
> 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...>
> <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...>>__>__>__>
>
>
> 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...>
> <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...>>__>__>__>
>
>
> 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...>
> <mailto:stp...@na... <mailto:stp...@na...>>
> <mailto:stp...@na... <mailto:stp...@na...>
> <mailto:stp...@na... <mailto:stp...@na...>>>
> <mailto:stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na... <mailto:stp...@na...>>
> <mailto:stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>>>
>
>
> Hi Borja.
> This is 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...>>
> <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...
> <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,
> 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...>>
> <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...
> <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...>>>>>>
>
>
> 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...>>>
>
> <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...
> <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...> <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...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>
>
> <mailto:stp...@na... <mailto:stp...@na...>
> <mailto:stp...@na... <mailto:stp...@na...>>
> <mailto:stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>>>>__>
>
>
>
> Hi Borja,
>
>
> >
> 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...>>__>__>
>
>
> <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...
> <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...>
> <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...
> <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...>>
> <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...
> <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...> <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...
> <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...>>>>
>
> <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...
> <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...> <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...
> <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...>>
> <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... <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...>
> <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... <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...>>>>
>
> <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...
> <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...> <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...
> <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...>>
> <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... <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...>
> <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... <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...>>__>__>
>
>
> <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...
> <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...>
> <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...
> <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...>>
> <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...
> <mailto:bor...@gm...>>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>
>
>
|
|
From: Stepan D. <stp...@na...> - 2013-07-10 19:15:26
|
Hi Borja,
> About the patch:
> Is all the code in AVRISelLowering.cpp necesarry? I find it to be a very
> "manual" way of doing this optimization, it feels like not being very
> general, so please confirm me that this the only way of doing it. Im
> asking this in case in AVRISelDAGToDAG.cpp you could add some code to
> match this sort of DAGs with the existing adressing mode matching
> functions to avoid the code in the other file. Maybe look at what other
> backends do?
I've compared it with ARM backend today (the only one that does
something serious with InlineAsm node).
Well all stuff I did in LowerINLINEASM is implemented in
SelectInlineAsm, in ARMISelDAGToDAG.
Well that's true, its not a lowering. I closer to the final stage, when
you just correct the things and select proper instructions.
So I did the same: I've moved everything from LowerINLINEASM to
SelectInlineAsm. The new patch is attached.
Theoretically, we can move everything related to memory constraint into
single SelectInlineAsm method. But in this case I'll need to check all
default behaviour that will be overridden. For me it is better to have
as much default behaviour as possible.
> In AVRISelDAGToDAG.cpp you've removed this line:
> cast<MemSDNode>(Op)->getMemoryVT().getSimpleVT();
> to be:
> + if (MemSDNode* MemNode = dyn_cast<MemSDNode>(Op))
> Is this condition always going to be true? the cast above never failed
> for me so in theory the dyn_cast should always be true, making the rest
> of elses there always false.
If Op is not a MemSDNode it dyn_cast will return false. So MemSDNode is
load or store node. InlineAsm in our case could play the same role too.
If you think it is some extra code in SelectAddr I can move it to
SelectInlineAsmMemoryOperand, though I'll have to copypaste something
from SelectAddr in this case.
-Stepan.
Borja Ferrer wrote:
> Jej no problem, I know you've been busy with some ARM stuff.
>
> Yes let's get this in first, and then we can talk about the multibyte stuff.
>
> About the patch:
> Is all the code in AVRISelLowering.cpp necesarry? I find it to be a very
> "manual" way of doing this optimization, it feels like not being very
> general, so please confirm me that this the only way of doing it. Im
> asking this in case in AVRISelDAGToDAG.cpp you could add some code to
> match this sort of DAGs with the existing adressing mode matching
> functions to avoid the code in the other file. Maybe look at what other
> backends do?
>
> In AVRISelDAGToDAG.cpp you've removed this line:
> cast<MemSDNode>(Op)->getMemoryVT().getSimpleVT();
> to be:
> + if (MemSDNode* MemNode = dyn_cast<MemSDNode>(Op))
> Is this condition always going to be true? the cast above never failed
> for me so in theory the dyn_cast should always be true, making the rest
> of elses there always false.
>
>
>
> 2013/7/9 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>>
>
> Hello Borja,
> Sorry for latency, I had to be on dev. meeting.
> I've implemented optimization for memory constraint support. The
> patch is in attachment.
>
> P.S.: When I started to work on this opt, I forgot about multibyte
> constraints patch is not committed. So I can send it after we commit
> this opt.
>
> -Stepan.
>
> Borja Ferrer wrote:
>
> Yes but the first goal now is to have inline asm feature complete xD
> Then we can move into other places of the library.
>
> Taking a look at the previous emails this is what needs still to
> be done:
> 1) Implement the missed optimization above for the memory
> constraint.
> Also see if you can come with further cases. Remember to add a
> test case.
> 2) Implement the stuff in the "C names used in assembler code"
> section
> of the avrlibc manual. You mentioned some issues here in a
> previous email.
> 3) Implement the a0, a1, etc... constraints.
>
>
>
> 2013/7/1 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>
>
>
> 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...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>
> <mailto:bor...@gm...
> <mailto:bor...@gm...> <mailto: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...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>
> <mailto: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...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>
> <mailto: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...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>
> <mailto: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...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>
> <mailto: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...>
> <mailto:stp...@na... <mailto:stp...@na...>>
> <mailto:stp...@na...
> <mailto:stp...@na...>
> <mailto: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...>>
>
> <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, 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...>>
> <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...>>>>>
>
> 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...>>>
>
>
> <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... <mailto:stp...@na...>>>
>
>
> <mailto:stp...@na... <mailto:stp...@na...>
> <mailto:stp...@na... <mailto:stp...@na...>>
> <mailto:stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na... <mailto:stp...@na...>>>>>>
>
>
>
> Hi Borja,
>
> >
> 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...>>__>__>
>
>
> <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...
> <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...>
> <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... <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...>>>>
>
> <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... <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...>
> <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...
> <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...>>>>
>
> <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... <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...>
> <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...
> <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...>>__>__>
>
>
> <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...
> <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...>
> <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... <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______forge.net>
>
>
>
> <http://source____forge.net>
>
> <http://source__forge.net>
>
> <http://source
> <http://sourceforge.net>
>
>
>
>
>
>
>
>
>
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-09 14:22:08
|
Jej no problem, I know you've been busy with some ARM stuff.
Yes let's get this in first, and then we can talk about the multibyte stuff.
About the patch:
Is all the code in AVRISelLowering.cpp necesarry? I find it to be a very
"manual" way of doing this optimization, it feels like not being very
general, so please confirm me that this the only way of doing it. Im asking
this in case in AVRISelDAGToDAG.cpp you could add some code to match this
sort of DAGs with the existing adressing mode matching functions to avoid
the code in the other file. Maybe look at what other backends do?
In AVRISelDAGToDAG.cpp you've removed this line:
cast<MemSDNode>(Op)->getMemoryVT().getSimpleVT();
to be:
+ if (MemSDNode* MemNode = dyn_cast<MemSDNode>(Op))
Is this condition always going to be true? the cast above never failed for
me so in theory the dyn_cast should always be true, making the rest of
elses there always false.
2013/7/9 Stepan Dyatkovskiy <stp...@na...>
> Hello Borja,
> Sorry for latency, I had to be on dev. meeting.
> I've implemented optimization for memory constraint support. The patch is
> in attachment.
>
> P.S.: When I started to work on this opt, I forgot about multibyte
> constraints patch is not committed. So I can send it after we commit this
> opt.
>
> -Stepan.
>
> Borja Ferrer wrote:
>
>> Yes but the first goal now is to have inline asm feature complete xD
>> Then we can move into other places of the library.
>>
>> Taking a look at the previous emails this is what needs still to be done:
>> 1) Implement the missed optimization above for the memory constraint.
>> Also see if you can come with further cases. Remember to add a test case.
>> 2) Implement the stuff in the "C names used in assembler code" section
>> of the avrlibc manual. You mentioned some issues here in a previous email.
>> 3) Implement the a0, a1, etc... constraints.
>>
>>
>>
>> 2013/7/1 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...
>> >>
>>
>>
>> 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...>
>> <mailto: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...>
>> <mailto: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...>
>> <mailto: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...>
>> <mailto: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...>
>> <mailto: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...>
>> <mailto: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...>**>
>>
>> <mailto: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...>>
>>
>> <mailto: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...>>>
>> <mailto:stp...@na...
>> <mailto:stp...@na...>
>> <mailto:stp...@na...
>> <mailto:stp...@na...>>
>>
>> <mailto:stp...@na...
>> <mailto:stp...@na...>
>> <mailto:stp...@na...
>> <mailto:stp...@na...>>>>>
>>
>>
>> Hi Borja,
>>
>> >
>> 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...>**>__>__>
>>
>> <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...
>> <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...>>>>
>>
>> <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...
>> <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...>>>>
>>
>> <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...
>> <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...>**>__>__>
>>
>> <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...
>> <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______forge.net>
>>
>>
>> <http://source____forge.net
>> >
>>
>> <http://source__forge.net>
>>
>> <http://source <
>> http://sourceforge.net>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-07-09 13:05:08
|
Hello Borja,
Sorry for latency, I had to be on dev. meeting.
I've implemented optimization for memory constraint support. The patch
is in attachment.
P.S.: When I started to work on this opt, I forgot about multibyte
constraints patch is not committed. So I can send it after we commit
this opt.
-Stepan.
Borja Ferrer wrote:
> Yes but the first goal now is to have inline asm feature complete xD
> Then we can move into other places of the library.
>
> Taking a look at the previous emails this is what needs still to be done:
> 1) Implement the missed optimization above for the memory constraint.
> Also see if you can come with further cases. Remember to add a test case.
> 2) Implement the stuff in the "C names used in assembler code" section
> of the avrlibc manual. You mentioned some issues here in a previous email.
> 3) Implement the a0, a1, etc... constraints.
>
>
>
> 2013/7/1 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>>
>
> 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...>
> <mailto: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...>
> <mailto: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...>
> <mailto: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...>
> <mailto: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...>
> <mailto: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...>
> <mailto: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...>>
>
> <mailto: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...>>
>
> <mailto: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...>>>
> <mailto:stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na...
> <mailto:stp...@na...>>
>
> <mailto:stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na...
> <mailto:stp...@na...>>>>>
>
>
> Hi Borja,
>
> >
> 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...>>__>__>
>
> <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...
> <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...>>>>
>
> <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...
> <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...>>>>
>
> <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...
> <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...>>__>__>
>
> <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...
> <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__forge.net>
>
> <http://source <http://sourceforge.net>
>
>
>
>
>
>
>
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-01 17:41:04
|
Yes but the first goal now is to have inline asm feature complete xD Then
we can move into other places of the library.
Taking a look at the previous emails this is what needs still to be done:
1) Implement the missed optimization above for the memory constraint. Also
see if you can come with further cases. Remember to add a test case.
2) Implement the stuff in the "C names used in assembler code" section of
the avrlibc manual. You mentioned some issues here in a previous email.
3) Implement the a0, a1, etc... constraints.
2013/7/1 Stepan Dyatkovskiy <stp...@na...>
> 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__forge.net>
>>
>> <http://source <http://sourceforge.net>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
|
|
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>
>
>
>
>
>
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-30 12:42:13
|
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...>
> 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...>
>
>> 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...>
>>
>>> 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...>
>>>
>>>> 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...>
>>>>
>>>>> 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...>
>>>>>
>>>>>> Hi Borja.
>>>>>> This is almost the final multibyte constraint patch. Tests are not
>>>>>> created yet.
>>>>>>
>>>>>> Currently I have issue with 64 bit values. Even if I pass them as
>>>>>> inline asm operands, llvm still truncates them to i32.
>>>>>>
>>>>>> What works:
>>>>>>
>>>>>> long a; // 32 bit
>>>>>> void f() {
>>>>>> asm("instr %A0 %B0 %C0 %D0": : "r"(a));
>>>>>> }
>>>>>>
>>>>>>
>>>>>> What doesn't work:
>>>>>>
>>>>>> long long a; // 64 bit
>>>>>> void f() {
>>>>>> asm("instr %A0 %B0 %E0": : "r"(a));
>>>>>> }
>>>>>>
>>>>>> The last one fires assertion since llvm allocates registers for the
>>>>>> first 32 bits only.
>>>>>>
>>>>>> -Stepan.
>>>>>>
>>>>>> Borja Ferrer wrote:
>>>>>>
>>>>>>> Yes fine
>>>>>>>
>>>>>>> El jueves, 27 de junio de 2013, Stepan Dyatkovskiy escribió:
>>>>>>>
>>>>>>> OK. Will do.
>>>>>>> Currently there is a patch with memory constraint and draft
>>>>>>> multibyte constraint (supports only A and B). To be clean under
>>>>>>> multibyte constraints I mean something like this:
>>>>>>> asm volatile("mov __tmp_reg__, %A0" "\n\t"
>>>>>>> "mov %A0, %B0" "\n\t"
>>>>>>> "mov %B0, __tmp_reg__" "\n\t"
>>>>>>> : "=r" (value)
>>>>>>> : "0" (value)
>>>>>>> );
>>>>>>>
>>>>>>> -Stepan.
>>>>>>> Borja Ferrer wrote:
>>>>>>>
>>>>>>> btw, if this is now feature complete you can commit it.
>>>>>>>
>>>>>>>
>>>>>>> 2013/6/27 Borja Ferrer <bor...@gm...
>>>>>>> <mailto:bor...@gm...>**>
>>>>>>>
>>>>>>> No, that code is a personal modification of your
>>>>>>> examples.
>>>>>>> If you
>>>>>>> aren't getting the correct output from clang that's
>>>>>>> because you
>>>>>>> probably didn't apply a patch i commited last week for
>>>>>>> clang in our SVN.
>>>>>>> The assertion you're getting looks reasonable, it's an
>>>>>>> old
>>>>>>> friend of
>>>>>>> mine. The reason is that if Y is being reserved as the
>>>>>>> frame
>>>>>>> pointer, you cant have an instruction that uses 2
>>>>>>> registers
>>>>>>> when
>>>>>>> only Z is available. I wouldn't mind too much about it.
>>>>>>>
>>>>>>> Now, my 2nd question:
>>>>>>>
>>>>>>> Is there anything else that needs to be covered for the
>>>>>>> memory
>>>>>>> constraint?
>>>>>>>
>>>>>>>
>>>>>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>>>>>>> <mailto:stp...@na...>>
>>>>>>>
>>>>>>> This one looks good. Though ./llc emits "run out of
>>>>>>> registers
>>>>>>> allocation. I'll look at it. Is that from avr-libc?
>>>>>>> -Stepan.
>>>>>>> Borja Ferrer wrote:
>>>>>>>
>>>>>>> Yes, and then I replied the following:
>>>>>>>
>>>>>>> For this C code:
>>>>>>>
>>>>>>> char delay_count;
>>>>>>> char aaa;
>>>>>>> uint8_t delay(unsigned char p)
>>>>>>> {
>>>>>>> uint8_t cnt;
>>>>>>> asm volatile (
>>>>>>> "inst %0, %1" "\n\t"
>>>>>>> : "=Q" (delay_count)
>>>>>>> : "Q" (aaa));
>>>>>>> return cnt;
>>>>>>> }
>>>>>>>
>>>>>>> Clang produces:
>>>>>>>
>>>>>>> define i8 @delay(i8 %p) #0 {
>>>>>>> entry:
>>>>>>> tail call void asm sideeffect "inst $0,
>>>>>>> $1\0A\09",
>>>>>>> "=*Q,*Q"(i8*
>>>>>>> @delay_count, i8* @aaa) #2, !srcloc !4
>>>>>>> ret i8 undef
>>>>>>> }
>>>>>>>
>>>>>>> notice the *Q constraints, so is there anything
>>>>>>> wrong in there?
>>>>>>>
>>>>>>> Is there anything else that needs to be covered
>>>>>>> for the
>>>>>>> memory constraint?
>>>>>>>
>>>>>>>
>>>>>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>>>>>>> <mailto:stp...@na...> <mailto:
>>>>>>> stp...@na...
>>>>>>> <mailto:stp...@na...>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Borja,
>>>>>>>
>>>>>>> > Stepan, reply in this thread to my 2
>>>>>>> questions again
>>>>>>> if the email
>>>>>>> got lost.
>>>>>>>
>>>>>>> My prev. reply:
>>>>>>>
>>>>>>>
>>>>>>> > Ahh, I didn't know avr-gcc was buggy on
>>>>>>> this
>>>>>>> feature, that's probably
>>>>>>> > the reason for why the code i pasted in
>>>>>>> my
>>>>>>> previous
>>>>>>> email didn't
>>>>>>> work.
>>>>>>> ...
>>>>>>> > What's wrong with clang? I fixed clang
>>>>>>> inline asm
>>>>>>> support back on
>>>>>>> > friday, so is there anything else that
>>>>>>> is
>>>>>>> broken?
>>>>>>> It should emit '*Q' instead of 'Q'. That's
>>>>>>> why
>>>>>>> code
>>>>>>> from prev. email
>>>>>>> didn't work, just compare -emit-llvm -S
>>>>>>> output of
>>>>>>> avr-clang with
>>>>>>> other backends,
>>>>>>>
>>>>>>> > About the getPointerRegClass function,
>>>>>>> what
>>>>>>> is it
>>>>>>> used for? Also,
>>>>>>> please
>>>>>>> > move the implementation to the cpp file
>>>>>>> instead of
>>>>>>> leaving it in
>>>>>>> the .h.
>>>>>>> Currently, it is used in registers
>>>>>>> coelescing
>>>>>>> pass.
>>>>>>> While being
>>>>>>> registers inflating, llvm lookups all
>>>>>>> register
>>>>>>> uses. If
>>>>>>> it found
>>>>>>> that register is used by inline-asm as
>>>>>>> memory
>>>>>>> operand,
>>>>>>> it requests
>>>>>>> the pointer class with this method (I think
>>>>>>> the largest
>>>>>>> one). But
>>>>>>> may be in future this method will be used
>>>>>>> in
>>>>>>> more cases.
>>>>>>>
>>>>>>> avr-gcc has buggy implementation of memory
>>>>>>> constraint,
>>>>>>> that's why
>>>>>>> avr-libs doesn't use it at all. We have a
>>>>>>> chance to be
>>>>>>> first here
>>>>>>>
>>>>>>> -Stepan
>>>>>>>
>>>>>>> Borja Ferrer wrote:
>>>>>>>
>>>>>>> Stepan, reply in this thread to my 2
>>>>>>> questions
>>>>>>> again if the
>>>>>>> email got lost.
>>>>>>>
>>>>>>>
>>>>>>> 2013/6/27 Borja Ferrer <
>>>>>>> bor...@gm...
>>>>>>> <mailto:bor...@gm...>
>>>>>>> <mailto:bor...@gm...
>>>>>>> <mailto:bor...@gm...>**>
>>>>>>> <mailto:bor...@gm...
>>>>>>> <mailto:bor...@gm...>
>>>>>>> <mailto:bor...@gm...
>>>>>>> <mailto:bor...@gm...>**>__>__>
>>>>>>>
>>>>>>>
>>>>>>> No, your last email only says :
>>>>>>> "So,
>>>>>>> can I
>>>>>>> commit that memory
>>>>>>> constraint patch?"
>>>>>>>
>>>>>>>
>>>>>>> 2013/6/27 Stepan Dyatkovskiy
>>>>>>> <stp...@na... <mailto:stp...@na...>
>>>>>>> <mailto:stp...@na...
>>>>>>> <mailto:stp...@na...>>
>>>>>>> <mailto:stp...@na...
>>>>>>> <mailto:stp...@na...> <mailto:
>>>>>>> stp...@na...
>>>>>>> <mailto:stp...@na...>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hm... Didn't you get my
>>>>>>> previous
>>>>>>> mail? If
>>>>>>> not, I think,
>>>>>>> I have
>>>>>>> to change my mail box.
>>>>>>>
>>>>>>> -Stepan
>>>>>>>
>>>>>>>
>>>>>>> -------- Original Message
>>>>>>> --------
>>>>>>> Subject: Re: [avr-llvm-devel]
>>>>>>> Inline
>>>>>>> assembly. Mostly
>>>>>>> just a stub.
>>>>>>> Date: Tue, 25 Jun 2013
>>>>>>> 18:30:46 +0400
>>>>>>> From: Stepan Dyatkovskiy
>>>>>>> <stp...@na... <mailto:stp...@na...>
>>>>>>> <mailto:stp...@na...
>>>>>>> <mailto:stp...@na...>>
>>>>>>> <mailto:stp...@na...
>>>>>>> <mailto:stp...@na...> <mailto:
>>>>>>> stp...@na...
>>>>>>> <mailto:stp...@na...>>>>
>>>>>>> To: Borja Ferrer
>>>>>>> <bor...@gm...
>>>>>>> <mailto:bor...@gm...>
>>>>>>> <mailto:bor...@gm...
>>>>>>> <mailto:bor...@gm...>**>
>>>>>>> <mailto:bor...@gm...
>>>>>>> <mailto:bor...@gm...>
>>>>>>> <mailto:bor...@gm...
>>>>>>> <mailto:bor...@gm...>**>__>__>
>>>>>>> CC: avr-llvm
>>>>>>> <avr-llvm-devel@lists.__source**______forge.net<http://source______forge.net>
>>>>>>> <http://source____forge.net>
>>>>>>> <http://source__forge.net>
>>>>>>> <http://source <http://sourceforge.net
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-29 21:35:01
|
Yup. We can keep that behavour then. May be we have to add an assertion, than only up to 32 bit types are supported.
About movw + adiw, have you tried it with O2?
> 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 > >> 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 >> >>> 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 >>> >>>> 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 >>>> >>>>> 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 >>>>> >>>>>> 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 >>>>>> >>>>>>> > >>>>>>> >>>>>>> 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 >>>>>> >>>>>>> > >>>>>>> >>>>>>> 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 >>>>>> >>>>>>> >>>>>> >>>>>>> >> >>>>>>> >>>>>>> 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 >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> > >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> >__>__> >>>>>>> >>>>>>> No, your last email only says : "So, >>>>>>> >>>>>>> can I >>>>>>> >>>>>>> commit that memory >>>>>>> >>>>>>> constraint patch?" >>>>>>> >>>>>>> 2013/6/27 Stepan Dyatkovskiy >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> > >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>> >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> > >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>> >>>>>>> >>>>>>> To: Borja Ferrer >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> > >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> >__>__> >>>>>>> >>>>>>> CC: avr-llvm >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- Truly yours, Stepan Dyatkovskiy |
|
From: Borja F. <bor...@gm...> - 2013-06-29 15:13:10
|
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...>
> 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...>
>
>> 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...>
>>
>>> 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...>
>>>
>>>> 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...>
>>>>
>>>>> Hi Borja.
>>>>> This is almost the final multibyte constraint patch. Tests are not
>>>>> created yet.
>>>>>
>>>>> Currently I have issue with 64 bit values. Even if I pass them as
>>>>> inline asm operands, llvm still truncates them to i32.
>>>>>
>>>>> What works:
>>>>>
>>>>> long a; // 32 bit
>>>>> void f() {
>>>>> asm("instr %A0 %B0 %C0 %D0": : "r"(a));
>>>>> }
>>>>>
>>>>>
>>>>> What doesn't work:
>>>>>
>>>>> long long a; // 64 bit
>>>>> void f() {
>>>>> asm("instr %A0 %B0 %E0": : "r"(a));
>>>>> }
>>>>>
>>>>> The last one fires assertion since llvm allocates registers for the
>>>>> first 32 bits only.
>>>>>
>>>>> -Stepan.
>>>>>
>>>>> Borja Ferrer wrote:
>>>>>
>>>>>> Yes fine
>>>>>>
>>>>>> El jueves, 27 de junio de 2013, Stepan Dyatkovskiy escribió:
>>>>>>
>>>>>> OK. Will do.
>>>>>> Currently there is a patch with memory constraint and draft
>>>>>> multibyte constraint (supports only A and B). To be clean under
>>>>>> multibyte constraints I mean something like this:
>>>>>> asm volatile("mov __tmp_reg__, %A0" "\n\t"
>>>>>> "mov %A0, %B0" "\n\t"
>>>>>> "mov %B0, __tmp_reg__" "\n\t"
>>>>>> : "=r" (value)
>>>>>> : "0" (value)
>>>>>> );
>>>>>>
>>>>>> -Stepan.
>>>>>> Borja Ferrer wrote:
>>>>>>
>>>>>> btw, if this is now feature complete you can commit it.
>>>>>>
>>>>>>
>>>>>> 2013/6/27 Borja Ferrer <bor...@gm...
>>>>>> <mailto:bor...@gm...>**>
>>>>>>
>>>>>> No, that code is a personal modification of your
>>>>>> examples.
>>>>>> If you
>>>>>> aren't getting the correct output from clang that's
>>>>>> because you
>>>>>> probably didn't apply a patch i commited last week for
>>>>>> clang in our SVN.
>>>>>> The assertion you're getting looks reasonable, it's an
>>>>>> old
>>>>>> friend of
>>>>>> mine. The reason is that if Y is being reserved as the
>>>>>> frame
>>>>>> pointer, you cant have an instruction that uses 2
>>>>>> registers
>>>>>> when
>>>>>> only Z is available. I wouldn't mind too much about it.
>>>>>>
>>>>>> Now, my 2nd question:
>>>>>>
>>>>>> Is there anything else that needs to be covered for the
>>>>>> memory
>>>>>> constraint?
>>>>>>
>>>>>>
>>>>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>>>>>> <mailto:stp...@na...>>
>>>>>>
>>>>>> This one looks good. Though ./llc emits "run out of
>>>>>> registers
>>>>>> allocation. I'll look at it. Is that from avr-libc?
>>>>>> -Stepan.
>>>>>> Borja Ferrer wrote:
>>>>>>
>>>>>> Yes, and then I replied the following:
>>>>>>
>>>>>> For this C code:
>>>>>>
>>>>>> char delay_count;
>>>>>> char aaa;
>>>>>> uint8_t delay(unsigned char p)
>>>>>> {
>>>>>> uint8_t cnt;
>>>>>> asm volatile (
>>>>>> "inst %0, %1" "\n\t"
>>>>>> : "=Q" (delay_count)
>>>>>> : "Q" (aaa));
>>>>>> return cnt;
>>>>>> }
>>>>>>
>>>>>> Clang produces:
>>>>>>
>>>>>> define i8 @delay(i8 %p) #0 {
>>>>>> entry:
>>>>>> tail call void asm sideeffect "inst $0,
>>>>>> $1\0A\09",
>>>>>> "=*Q,*Q"(i8*
>>>>>> @delay_count, i8* @aaa) #2, !srcloc !4
>>>>>> ret i8 undef
>>>>>> }
>>>>>>
>>>>>> notice the *Q constraints, so is there anything
>>>>>> wrong in there?
>>>>>>
>>>>>> Is there anything else that needs to be covered
>>>>>> for the
>>>>>> memory constraint?
>>>>>>
>>>>>>
>>>>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>>>>>> <mailto:stp...@na...> <mailto:
>>>>>> stp...@na...
>>>>>> <mailto:stp...@na...>>>
>>>>>>
>>>>>>
>>>>>> Hi Borja,
>>>>>>
>>>>>> > Stepan, reply in this thread to my 2
>>>>>> questions again
>>>>>> if the email
>>>>>> got lost.
>>>>>>
>>>>>> My prev. reply:
>>>>>>
>>>>>>
>>>>>> > Ahh, I didn't know avr-gcc was buggy on
>>>>>> this
>>>>>> feature, that's probably
>>>>>> > the reason for why the code i pasted in
>>>>>> my
>>>>>> previous
>>>>>> email didn't
>>>>>> work.
>>>>>> ...
>>>>>> > What's wrong with clang? I fixed clang
>>>>>> inline asm
>>>>>> support back on
>>>>>> > friday, so is there anything else that is
>>>>>> broken?
>>>>>> It should emit '*Q' instead of 'Q'. That's
>>>>>> why
>>>>>> code
>>>>>> from prev. email
>>>>>> didn't work, just compare -emit-llvm -S
>>>>>> output of
>>>>>> avr-clang with
>>>>>> other backends,
>>>>>>
>>>>>> > About the getPointerRegClass function,
>>>>>> what
>>>>>> is it
>>>>>> used for? Also,
>>>>>> please
>>>>>> > move the implementation to the cpp file
>>>>>> instead of
>>>>>> leaving it in
>>>>>> the .h.
>>>>>> Currently, it is used in registers
>>>>>> coelescing
>>>>>> pass.
>>>>>> While being
>>>>>> registers inflating, llvm lookups all
>>>>>> register
>>>>>> uses. If
>>>>>> it found
>>>>>> that register is used by inline-asm as
>>>>>> memory
>>>>>> operand,
>>>>>> it requests
>>>>>> the pointer class with this method (I think
>>>>>> the largest
>>>>>> one). But
>>>>>> may be in future this method will be used in
>>>>>> more cases.
>>>>>>
>>>>>> avr-gcc has buggy implementation of memory
>>>>>> constraint,
>>>>>> that's why
>>>>>> avr-libs doesn't use it at all. We have a
>>>>>> chance to be
>>>>>> first here
>>>>>>
>>>>>> -Stepan
>>>>>>
>>>>>> Borja Ferrer wrote:
>>>>>>
>>>>>> Stepan, reply in this thread to my 2
>>>>>> questions
>>>>>> again if the
>>>>>> email got lost.
>>>>>>
>>>>>>
>>>>>> 2013/6/27 Borja Ferrer <
>>>>>> bor...@gm...
>>>>>> <mailto:bor...@gm...>
>>>>>> <mailto:bor...@gm...
>>>>>> <mailto:bor...@gm...>**>
>>>>>> <mailto:bor...@gm...
>>>>>> <mailto:bor...@gm...>
>>>>>> <mailto:bor...@gm...
>>>>>> <mailto:bor...@gm...>**>__>__>
>>>>>>
>>>>>>
>>>>>> No, your last email only says :
>>>>>> "So,
>>>>>> can I
>>>>>> commit that memory
>>>>>> constraint patch?"
>>>>>>
>>>>>>
>>>>>> 2013/6/27 Stepan Dyatkovskiy
>>>>>> <stp...@na... <mailto:stp...@na...>
>>>>>> <mailto:stp...@na...
>>>>>> <mailto:stp...@na...>>
>>>>>> <mailto:stp...@na...
>>>>>> <mailto:stp...@na...> <mailto:
>>>>>> stp...@na...
>>>>>> <mailto:stp...@na...>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hm... Didn't you get my
>>>>>> previous
>>>>>> mail? If
>>>>>> not, I think,
>>>>>> I have
>>>>>> to change my mail box.
>>>>>>
>>>>>> -Stepan
>>>>>>
>>>>>>
>>>>>> -------- Original Message
>>>>>> --------
>>>>>> Subject: Re: [avr-llvm-devel]
>>>>>> Inline
>>>>>> assembly. Mostly
>>>>>> just a stub.
>>>>>> Date: Tue, 25 Jun 2013
>>>>>> 18:30:46 +0400
>>>>>> From: Stepan Dyatkovskiy
>>>>>> <stp...@na... <mailto:stp...@na...>
>>>>>> <mailto:stp...@na...
>>>>>> <mailto:stp...@na...>>
>>>>>> <mailto:stp...@na...
>>>>>> <mailto:stp...@na...> <mailto:
>>>>>> stp...@na...
>>>>>> <mailto:stp...@na...>>>>
>>>>>> To: Borja Ferrer
>>>>>> <bor...@gm...
>>>>>> <mailto:bor...@gm...>
>>>>>> <mailto:bor...@gm...
>>>>>> <mailto:bor...@gm...>**>
>>>>>> <mailto:bor...@gm...
>>>>>> <mailto:bor...@gm...>
>>>>>> <mailto:bor...@gm...
>>>>>> <mailto:bor...@gm...>**>__>__>
>>>>>> CC: avr-llvm
>>>>>> <avr-llvm-devel@lists.__source**______forge.net<http://source______forge.net>
>>>>>> <http://source____forge.net>
>>>>>> <http://source__forge.net>
>>>>>> <http://source <http://sourceforge.net>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-29 14:14:06
|
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...>
> 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...>
>
>> 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...>
>>
>>> 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...>
>>>
>>>> Hi Borja.
>>>> This is almost the final multibyte constraint patch. Tests are not
>>>> created yet.
>>>>
>>>> Currently I have issue with 64 bit values. Even if I pass them as
>>>> inline asm operands, llvm still truncates them to i32.
>>>>
>>>> What works:
>>>>
>>>> long a; // 32 bit
>>>> void f() {
>>>> asm("instr %A0 %B0 %C0 %D0": : "r"(a));
>>>> }
>>>>
>>>>
>>>> What doesn't work:
>>>>
>>>> long long a; // 64 bit
>>>> void f() {
>>>> asm("instr %A0 %B0 %E0": : "r"(a));
>>>> }
>>>>
>>>> The last one fires assertion since llvm allocates registers for the
>>>> first 32 bits only.
>>>>
>>>> -Stepan.
>>>>
>>>> Borja Ferrer wrote:
>>>>
>>>>> Yes fine
>>>>>
>>>>> El jueves, 27 de junio de 2013, Stepan Dyatkovskiy escribió:
>>>>>
>>>>> OK. Will do.
>>>>> Currently there is a patch with memory constraint and draft
>>>>> multibyte constraint (supports only A and B). To be clean under
>>>>> multibyte constraints I mean something like this:
>>>>> asm volatile("mov __tmp_reg__, %A0" "\n\t"
>>>>> "mov %A0, %B0" "\n\t"
>>>>> "mov %B0, __tmp_reg__" "\n\t"
>>>>> : "=r" (value)
>>>>> : "0" (value)
>>>>> );
>>>>>
>>>>> -Stepan.
>>>>> Borja Ferrer wrote:
>>>>>
>>>>> btw, if this is now feature complete you can commit it.
>>>>>
>>>>>
>>>>> 2013/6/27 Borja Ferrer <bor...@gm...
>>>>> <mailto:bor...@gm...>**>
>>>>>
>>>>> No, that code is a personal modification of your examples.
>>>>> If you
>>>>> aren't getting the correct output from clang that's
>>>>> because you
>>>>> probably didn't apply a patch i commited last week for
>>>>> clang in our SVN.
>>>>> The assertion you're getting looks reasonable, it's an old
>>>>> friend of
>>>>> mine. The reason is that if Y is being reserved as the
>>>>> frame
>>>>> pointer, you cant have an instruction that uses 2
>>>>> registers
>>>>> when
>>>>> only Z is available. I wouldn't mind too much about it.
>>>>>
>>>>> Now, my 2nd question:
>>>>>
>>>>> Is there anything else that needs to be covered for the
>>>>> memory
>>>>> constraint?
>>>>>
>>>>>
>>>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>>>>> <mailto:stp...@na...>>
>>>>>
>>>>> This one looks good. Though ./llc emits "run out of
>>>>> registers
>>>>> allocation. I'll look at it. Is that from avr-libc?
>>>>> -Stepan.
>>>>> Borja Ferrer wrote:
>>>>>
>>>>> Yes, and then I replied the following:
>>>>>
>>>>> For this C code:
>>>>>
>>>>> char delay_count;
>>>>> char aaa;
>>>>> uint8_t delay(unsigned char p)
>>>>> {
>>>>> uint8_t cnt;
>>>>> asm volatile (
>>>>> "inst %0, %1" "\n\t"
>>>>> : "=Q" (delay_count)
>>>>> : "Q" (aaa));
>>>>> return cnt;
>>>>> }
>>>>>
>>>>> Clang produces:
>>>>>
>>>>> define i8 @delay(i8 %p) #0 {
>>>>> entry:
>>>>> tail call void asm sideeffect "inst $0,
>>>>> $1\0A\09",
>>>>> "=*Q,*Q"(i8*
>>>>> @delay_count, i8* @aaa) #2, !srcloc !4
>>>>> ret i8 undef
>>>>> }
>>>>>
>>>>> notice the *Q constraints, so is there anything
>>>>> wrong in there?
>>>>>
>>>>> Is there anything else that needs to be covered
>>>>> for the
>>>>> memory constraint?
>>>>>
>>>>>
>>>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>>>>> <mailto:stp...@na...> <mailto:
>>>>> stp...@na...
>>>>> <mailto:stp...@na...>>>
>>>>>
>>>>>
>>>>> Hi Borja,
>>>>>
>>>>> > Stepan, reply in this thread to my 2
>>>>> questions again
>>>>> if the email
>>>>> got lost.
>>>>>
>>>>> My prev. reply:
>>>>>
>>>>>
>>>>> > Ahh, I didn't know avr-gcc was buggy on
>>>>> this
>>>>> feature, that's probably
>>>>> > the reason for why the code i pasted in my
>>>>> previous
>>>>> email didn't
>>>>> work.
>>>>> ...
>>>>> > What's wrong with clang? I fixed clang
>>>>> inline asm
>>>>> support back on
>>>>> > friday, so is there anything else that is
>>>>> broken?
>>>>> It should emit '*Q' instead of 'Q'. That's
>>>>> why
>>>>> code
>>>>> from prev. email
>>>>> didn't work, just compare -emit-llvm -S
>>>>> output of
>>>>> avr-clang with
>>>>> other backends,
>>>>>
>>>>> > About the getPointerRegClass function,
>>>>> what
>>>>> is it
>>>>> used for? Also,
>>>>> please
>>>>> > move the implementation to the cpp file
>>>>> instead of
>>>>> leaving it in
>>>>> the .h.
>>>>> Currently, it is used in registers coelescing
>>>>> pass.
>>>>> While being
>>>>> registers inflating, llvm lookups all
>>>>> register
>>>>> uses. If
>>>>> it found
>>>>> that register is used by inline-asm as memory
>>>>> operand,
>>>>> it requests
>>>>> the pointer class with this method (I think
>>>>> the largest
>>>>> one). But
>>>>> may be in future this method will be used in
>>>>> more cases.
>>>>>
>>>>> avr-gcc has buggy implementation of memory
>>>>> constraint,
>>>>> that's why
>>>>> avr-libs doesn't use it at all. We have a
>>>>> chance to be
>>>>> first here
>>>>>
>>>>> -Stepan
>>>>>
>>>>> Borja Ferrer wrote:
>>>>>
>>>>> Stepan, reply in this thread to my 2
>>>>> questions
>>>>> again if the
>>>>> email got lost.
>>>>>
>>>>>
>>>>> 2013/6/27 Borja Ferrer <
>>>>> bor...@gm...
>>>>> <mailto:bor...@gm...>
>>>>> <mailto:bor...@gm...
>>>>> <mailto:bor...@gm...>**>
>>>>> <mailto:bor...@gm...
>>>>> <mailto:bor...@gm...>
>>>>> <mailto:bor...@gm...
>>>>> <mailto:bor...@gm...>**>__>__>
>>>>>
>>>>>
>>>>> No, your last email only says : "So,
>>>>> can I
>>>>> commit that memory
>>>>> constraint patch?"
>>>>>
>>>>>
>>>>> 2013/6/27 Stepan Dyatkovskiy
>>>>> <stp...@na... <mailto:stp...@na...>
>>>>> <mailto:stp...@na...
>>>>> <mailto:stp...@na...>>
>>>>> <mailto:stp...@na...
>>>>> <mailto:stp...@na...> <mailto:
>>>>> stp...@na...
>>>>> <mailto:stp...@na...>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hm... Didn't you get my previous
>>>>> mail? If
>>>>> not, I think,
>>>>> I have
>>>>> to change my mail box.
>>>>>
>>>>> -Stepan
>>>>>
>>>>>
>>>>> -------- Original Message
>>>>> --------
>>>>> Subject: Re: [avr-llvm-devel]
>>>>> Inline
>>>>> assembly. Mostly
>>>>> just a stub.
>>>>> Date: Tue, 25 Jun 2013 18:30:46
>>>>> +0400
>>>>> From: Stepan Dyatkovskiy
>>>>> <stp...@na... <mailto:stp...@na...>
>>>>> <mailto:stp...@na...
>>>>> <mailto:stp...@na...>>
>>>>> <mailto:stp...@na...
>>>>> <mailto:stp...@na...> <mailto:
>>>>> stp...@na...
>>>>> <mailto:stp...@na...>>>>
>>>>> To: Borja Ferrer
>>>>> <bor...@gm...
>>>>> <mailto:bor...@gm...>
>>>>> <mailto:bor...@gm...
>>>>> <mailto:bor...@gm...>**>
>>>>> <mailto:bor...@gm...
>>>>> <mailto:bor...@gm...>
>>>>> <mailto:bor...@gm...
>>>>> <mailto:bor...@gm...>**>__>__>
>>>>> CC: avr-llvm
>>>>> <avr-llvm-devel@lists.__source**______forge.net<http://source______forge.net>
>>>>> <http://source____forge.net>
>>>>> <http://source__forge.net>
>>>>> <http://source <http://sourceforge.net>
>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-29 13:51:19
|
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...>
> 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...>
>
>> 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...>
>>
>>> Hi Borja.
>>> This is almost the final multibyte constraint patch. Tests are not
>>> created yet.
>>>
>>> Currently I have issue with 64 bit values. Even if I pass them as inline
>>> asm operands, llvm still truncates them to i32.
>>>
>>> What works:
>>>
>>> long a; // 32 bit
>>> void f() {
>>> asm("instr %A0 %B0 %C0 %D0": : "r"(a));
>>> }
>>>
>>>
>>> What doesn't work:
>>>
>>> long long a; // 64 bit
>>> void f() {
>>> asm("instr %A0 %B0 %E0": : "r"(a));
>>> }
>>>
>>> The last one fires assertion since llvm allocates registers for the
>>> first 32 bits only.
>>>
>>> -Stepan.
>>>
>>> Borja Ferrer wrote:
>>>
>>>> Yes fine
>>>>
>>>> El jueves, 27 de junio de 2013, Stepan Dyatkovskiy escribió:
>>>>
>>>> OK. Will do.
>>>> Currently there is a patch with memory constraint and draft
>>>> multibyte constraint (supports only A and B). To be clean under
>>>> multibyte constraints I mean something like this:
>>>> asm volatile("mov __tmp_reg__, %A0" "\n\t"
>>>> "mov %A0, %B0" "\n\t"
>>>> "mov %B0, __tmp_reg__" "\n\t"
>>>> : "=r" (value)
>>>> : "0" (value)
>>>> );
>>>>
>>>> -Stepan.
>>>> Borja Ferrer wrote:
>>>>
>>>> btw, if this is now feature complete you can commit it.
>>>>
>>>>
>>>> 2013/6/27 Borja Ferrer <bor...@gm...
>>>> <mailto:bor...@gm...>**>
>>>>
>>>> No, that code is a personal modification of your examples.
>>>> If you
>>>> aren't getting the correct output from clang that's
>>>> because you
>>>> probably didn't apply a patch i commited last week for
>>>> clang in our SVN.
>>>> The assertion you're getting looks reasonable, it's an old
>>>> friend of
>>>> mine. The reason is that if Y is being reserved as the
>>>> frame
>>>> pointer, you cant have an instruction that uses 2 registers
>>>> when
>>>> only Z is available. I wouldn't mind too much about it.
>>>>
>>>> Now, my 2nd question:
>>>>
>>>> Is there anything else that needs to be covered for the
>>>> memory
>>>> constraint?
>>>>
>>>>
>>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>>>> <mailto:stp...@na...>>
>>>>
>>>> This one looks good. Though ./llc emits "run out of
>>>> registers
>>>> allocation. I'll look at it. Is that from avr-libc?
>>>> -Stepan.
>>>> Borja Ferrer wrote:
>>>>
>>>> Yes, and then I replied the following:
>>>>
>>>> For this C code:
>>>>
>>>> char delay_count;
>>>> char aaa;
>>>> uint8_t delay(unsigned char p)
>>>> {
>>>> uint8_t cnt;
>>>> asm volatile (
>>>> "inst %0, %1" "\n\t"
>>>> : "=Q" (delay_count)
>>>> : "Q" (aaa));
>>>> return cnt;
>>>> }
>>>>
>>>> Clang produces:
>>>>
>>>> define i8 @delay(i8 %p) #0 {
>>>> entry:
>>>> tail call void asm sideeffect "inst $0,
>>>> $1\0A\09",
>>>> "=*Q,*Q"(i8*
>>>> @delay_count, i8* @aaa) #2, !srcloc !4
>>>> ret i8 undef
>>>> }
>>>>
>>>> notice the *Q constraints, so is there anything
>>>> wrong in there?
>>>>
>>>> Is there anything else that needs to be covered
>>>> for the
>>>> memory constraint?
>>>>
>>>>
>>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>>>> <mailto:stp...@na...> <mailto:
>>>> stp...@na...
>>>> <mailto:stp...@na...>>>
>>>>
>>>>
>>>> Hi Borja,
>>>>
>>>> > Stepan, reply in this thread to my 2
>>>> questions again
>>>> if the email
>>>> got lost.
>>>>
>>>> My prev. reply:
>>>>
>>>>
>>>> > Ahh, I didn't know avr-gcc was buggy on
>>>> this
>>>> feature, that's probably
>>>> > the reason for why the code i pasted in my
>>>> previous
>>>> email didn't
>>>> work.
>>>> ...
>>>> > What's wrong with clang? I fixed clang
>>>> inline asm
>>>> support back on
>>>> > friday, so is there anything else that is
>>>> broken?
>>>> It should emit '*Q' instead of 'Q'. That's why
>>>> code
>>>> from prev. email
>>>> didn't work, just compare -emit-llvm -S
>>>> output of
>>>> avr-clang with
>>>> other backends,
>>>>
>>>> > About the getPointerRegClass function, what
>>>> is it
>>>> used for? Also,
>>>> please
>>>> > move the implementation to the cpp file
>>>> instead of
>>>> leaving it in
>>>> the .h.
>>>> Currently, it is used in registers coelescing
>>>> pass.
>>>> While being
>>>> registers inflating, llvm lookups all register
>>>> uses. If
>>>> it found
>>>> that register is used by inline-asm as memory
>>>> operand,
>>>> it requests
>>>> the pointer class with this method (I think
>>>> the largest
>>>> one). But
>>>> may be in future this method will be used in
>>>> more cases.
>>>>
>>>> avr-gcc has buggy implementation of memory
>>>> constraint,
>>>> that's why
>>>> avr-libs doesn't use it at all. We have a
>>>> chance to be
>>>> first here
>>>>
>>>> -Stepan
>>>>
>>>> Borja Ferrer wrote:
>>>>
>>>> Stepan, reply in this thread to my 2
>>>> questions
>>>> again if the
>>>> email got lost.
>>>>
>>>>
>>>> 2013/6/27 Borja Ferrer <
>>>> bor...@gm...
>>>> <mailto:bor...@gm...>
>>>> <mailto:bor...@gm...
>>>> <mailto:bor...@gm...>**>
>>>> <mailto:bor...@gm...
>>>> <mailto:bor...@gm...>
>>>> <mailto:bor...@gm...
>>>> <mailto:bor...@gm...>**>__>__>
>>>>
>>>>
>>>> No, your last email only says : "So,
>>>> can I
>>>> commit that memory
>>>> constraint patch?"
>>>>
>>>>
>>>> 2013/6/27 Stepan Dyatkovskiy
>>>> <stp...@na... <mailto:stp...@na...>
>>>> <mailto:stp...@na...
>>>> <mailto:stp...@na...>>
>>>> <mailto:stp...@na...
>>>> <mailto:stp...@na...> <mailto:
>>>> stp...@na...
>>>> <mailto:stp...@na...>>>>
>>>>
>>>>
>>>>
>>>> Hm... Didn't you get my previous
>>>> mail? If
>>>> not, I think,
>>>> I have
>>>> to change my mail box.
>>>>
>>>> -Stepan
>>>>
>>>>
>>>> -------- Original Message
>>>> --------
>>>> Subject: Re: [avr-llvm-devel]
>>>> Inline
>>>> assembly. Mostly
>>>> just a stub.
>>>> Date: Tue, 25 Jun 2013 18:30:46
>>>> +0400
>>>> From: Stepan Dyatkovskiy
>>>> <stp...@na... <mailto:stp...@na...>
>>>> <mailto:stp...@na...
>>>> <mailto:stp...@na...>>
>>>> <mailto:stp...@na...
>>>> <mailto:stp...@na...> <mailto:
>>>> stp...@na...
>>>> <mailto:stp...@na...>>>>
>>>> To: Borja Ferrer
>>>> <bor...@gm...
>>>> <mailto:bor...@gm...>
>>>> <mailto:bor...@gm...
>>>> <mailto:bor...@gm...>**>
>>>> <mailto:bor...@gm...
>>>> <mailto:bor...@gm...>
>>>> <mailto:bor...@gm...
>>>> <mailto:bor...@gm...>**>__>__>
>>>> CC: avr-llvm
>>>> <avr-llvm-devel@lists.__source**______forge.net<http://source______forge.net>
>>>> <http://source____forge.net>
>>>> <http://source__forge.net>
>>>> <http://source <http://sourceforge.net>
>>>>
>>>>
>>>
>>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-29 12:57:05
|
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...>
> 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...>
>
>> Hi Borja.
>> This is almost the final multibyte constraint patch. Tests are not
>> created yet.
>>
>> Currently I have issue with 64 bit values. Even if I pass them as inline
>> asm operands, llvm still truncates them to i32.
>>
>> What works:
>>
>> long a; // 32 bit
>> void f() {
>> asm("instr %A0 %B0 %C0 %D0": : "r"(a));
>> }
>>
>>
>> What doesn't work:
>>
>> long long a; // 64 bit
>> void f() {
>> asm("instr %A0 %B0 %E0": : "r"(a));
>> }
>>
>> The last one fires assertion since llvm allocates registers for the first
>> 32 bits only.
>>
>> -Stepan.
>>
>> Borja Ferrer wrote:
>>
>>> Yes fine
>>>
>>> El jueves, 27 de junio de 2013, Stepan Dyatkovskiy escribió:
>>>
>>> OK. Will do.
>>> Currently there is a patch with memory constraint and draft
>>> multibyte constraint (supports only A and B). To be clean under
>>> multibyte constraints I mean something like this:
>>> asm volatile("mov __tmp_reg__, %A0" "\n\t"
>>> "mov %A0, %B0" "\n\t"
>>> "mov %B0, __tmp_reg__" "\n\t"
>>> : "=r" (value)
>>> : "0" (value)
>>> );
>>>
>>> -Stepan.
>>> Borja Ferrer wrote:
>>>
>>> btw, if this is now feature complete you can commit it.
>>>
>>>
>>> 2013/6/27 Borja Ferrer <bor...@gm...
>>> <mailto:bor...@gm...>**>
>>>
>>> No, that code is a personal modification of your examples.
>>> If you
>>> aren't getting the correct output from clang that's because
>>> you
>>> probably didn't apply a patch i commited last week for
>>> clang in our SVN.
>>> The assertion you're getting looks reasonable, it's an old
>>> friend of
>>> mine. The reason is that if Y is being reserved as the frame
>>> pointer, you cant have an instruction that uses 2 registers
>>> when
>>> only Z is available. I wouldn't mind too much about it.
>>>
>>> Now, my 2nd question:
>>>
>>> Is there anything else that needs to be covered for the
>>> memory
>>> constraint?
>>>
>>>
>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>>> <mailto:stp...@na...>>
>>>
>>> This one looks good. Though ./llc emits "run out of
>>> registers
>>> allocation. I'll look at it. Is that from avr-libc?
>>> -Stepan.
>>> Borja Ferrer wrote:
>>>
>>> Yes, and then I replied the following:
>>>
>>> For this C code:
>>>
>>> char delay_count;
>>> char aaa;
>>> uint8_t delay(unsigned char p)
>>> {
>>> uint8_t cnt;
>>> asm volatile (
>>> "inst %0, %1" "\n\t"
>>> : "=Q" (delay_count)
>>> : "Q" (aaa));
>>> return cnt;
>>> }
>>>
>>> Clang produces:
>>>
>>> define i8 @delay(i8 %p) #0 {
>>> entry:
>>> tail call void asm sideeffect "inst $0,
>>> $1\0A\09",
>>> "=*Q,*Q"(i8*
>>> @delay_count, i8* @aaa) #2, !srcloc !4
>>> ret i8 undef
>>> }
>>>
>>> notice the *Q constraints, so is there anything
>>> wrong in there?
>>>
>>> Is there anything else that needs to be covered for
>>> the
>>> memory constraint?
>>>
>>>
>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>>> <mailto:stp...@na...> <mailto:
>>> stp...@na...
>>> <mailto:stp...@na...>>>
>>>
>>>
>>> Hi Borja,
>>>
>>> > Stepan, reply in this thread to my 2
>>> questions again
>>> if the email
>>> got lost.
>>>
>>> My prev. reply:
>>>
>>>
>>> > Ahh, I didn't know avr-gcc was buggy on this
>>> feature, that's probably
>>> > the reason for why the code i pasted in my
>>> previous
>>> email didn't
>>> work.
>>> ...
>>> > What's wrong with clang? I fixed clang
>>> inline asm
>>> support back on
>>> > friday, so is there anything else that is
>>> broken?
>>> It should emit '*Q' instead of 'Q'. That's why
>>> code
>>> from prev. email
>>> didn't work, just compare -emit-llvm -S output
>>> of
>>> avr-clang with
>>> other backends,
>>>
>>> > About the getPointerRegClass function, what
>>> is it
>>> used for? Also,
>>> please
>>> > move the implementation to the cpp file
>>> instead of
>>> leaving it in
>>> the .h.
>>> Currently, it is used in registers coelescing
>>> pass.
>>> While being
>>> registers inflating, llvm lookups all register
>>> uses. If
>>> it found
>>> that register is used by inline-asm as memory
>>> operand,
>>> it requests
>>> the pointer class with this method (I think
>>> the largest
>>> one). But
>>> may be in future this method will be used in
>>> more cases.
>>>
>>> avr-gcc has buggy implementation of memory
>>> constraint,
>>> that's why
>>> avr-libs doesn't use it at all. We have a
>>> chance to be
>>> first here
>>>
>>> -Stepan
>>>
>>> Borja Ferrer wrote:
>>>
>>> Stepan, reply in this thread to my 2
>>> questions
>>> again if the
>>> email got lost.
>>>
>>>
>>> 2013/6/27 Borja Ferrer <
>>> bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>__>__>
>>>
>>>
>>> No, your last email only says : "So,
>>> can I
>>> commit that memory
>>> constraint patch?"
>>>
>>>
>>> 2013/6/27 Stepan Dyatkovskiy
>>> <stp...@na... <mailto:stp...@na...>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...>>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...> <mailto:
>>> stp...@na...
>>> <mailto:stp...@na...>>>>
>>>
>>>
>>>
>>> Hm... Didn't you get my previous
>>> mail? If
>>> not, I think,
>>> I have
>>> to change my mail box.
>>>
>>> -Stepan
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: [avr-llvm-devel]
>>> Inline
>>> assembly. Mostly
>>> just a stub.
>>> Date: Tue, 25 Jun 2013 18:30:46
>>> +0400
>>> From: Stepan Dyatkovskiy
>>> <stp...@na... <mailto:stp...@na...>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...>>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...> <mailto:
>>> stp...@na...
>>> <mailto:stp...@na...>>>>
>>> To: Borja Ferrer
>>> <bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>__>__>
>>> CC: avr-llvm
>>> <avr-llvm-devel@lists.__source**______forge.net<http://source______forge.net>
>>> <http://source____forge.net>
>>> <http://source__forge.net>
>>> <http://source <http://sourceforge.net>
>>>
>>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-29 07:24:10
|
Hi Borja,
1. Yes, avr-gcc, supports i64.
2. Well I'd want to *keep* an assertion. IMHO ee should legalize operands that are bigger than i16 by expanding onto set of either i8 or i16 registers in future.
-Stepan
> 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 > >> 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 >> >>> > >>> >>> 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 >> >>> > >>> >>> 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 >> >>> >> >>> >> >>> >>> 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 >> >>> >>> >>> >> >>> > >>> >>> >> >>> >>> >>> >> >>> >__>__> >>> >>> No, your last email only says : "So, >>> >>> can I >>> >>> commit that memory >>> >>> constraint patch?" >>> >>> 2013/6/27 Stepan Dyatkovskiy >>> >>> >>> >>> >> >>> > >>> >>> >> >>> >> >>> >>> >>> >>> 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 >>> >>> >>> >>> >> >>> > >>> >>> >> >>> >> >>> >>> >>> >>> To: Borja Ferrer >>> >>> >> >>> >>> >>> >> >>> > >>> >>> >> >>> >>> >>> >> >>> >__>__> >>> >>> CC: avr-llvm >>> >>> >> >>> >>> >>> >>> >>> -- Truly yours, Stepan Dyatkovskiy |
|
From: Borja F. <bor...@gm...> - 2013-06-28 20:11:48
|
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...>
> Hi Borja.
> This is almost the final multibyte constraint patch. Tests are not created
> yet.
>
> Currently I have issue with 64 bit values. Even if I pass them as inline
> asm operands, llvm still truncates them to i32.
>
> What works:
>
> long a; // 32 bit
> void f() {
> asm("instr %A0 %B0 %C0 %D0": : "r"(a));
> }
>
>
> What doesn't work:
>
> long long a; // 64 bit
> void f() {
> asm("instr %A0 %B0 %E0": : "r"(a));
> }
>
> The last one fires assertion since llvm allocates registers for the first
> 32 bits only.
>
> -Stepan.
>
> Borja Ferrer wrote:
>
>> Yes fine
>>
>> El jueves, 27 de junio de 2013, Stepan Dyatkovskiy escribió:
>>
>> OK. Will do.
>> Currently there is a patch with memory constraint and draft
>> multibyte constraint (supports only A and B). To be clean under
>> multibyte constraints I mean something like this:
>> asm volatile("mov __tmp_reg__, %A0" "\n\t"
>> "mov %A0, %B0" "\n\t"
>> "mov %B0, __tmp_reg__" "\n\t"
>> : "=r" (value)
>> : "0" (value)
>> );
>>
>> -Stepan.
>> Borja Ferrer wrote:
>>
>> btw, if this is now feature complete you can commit it.
>>
>>
>> 2013/6/27 Borja Ferrer <bor...@gm...
>> <mailto:bor...@gm...>**>
>>
>> No, that code is a personal modification of your examples.
>> If you
>> aren't getting the correct output from clang that's because
>> you
>> probably didn't apply a patch i commited last week for
>> clang in our SVN.
>> The assertion you're getting looks reasonable, it's an old
>> friend of
>> mine. The reason is that if Y is being reserved as the frame
>> pointer, you cant have an instruction that uses 2 registers
>> when
>> only Z is available. I wouldn't mind too much about it.
>>
>> Now, my 2nd question:
>>
>> Is there anything else that needs to be covered for the
>> memory
>> constraint?
>>
>>
>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>> <mailto:stp...@na...>>
>>
>> This one looks good. Though ./llc emits "run out of
>> registers
>> allocation. I'll look at it. Is that from avr-libc?
>> -Stepan.
>> Borja Ferrer wrote:
>>
>> Yes, and then I replied the following:
>>
>> For this C code:
>>
>> char delay_count;
>> char aaa;
>> uint8_t delay(unsigned char p)
>> {
>> uint8_t cnt;
>> asm volatile (
>> "inst %0, %1" "\n\t"
>> : "=Q" (delay_count)
>> : "Q" (aaa));
>> return cnt;
>> }
>>
>> Clang produces:
>>
>> define i8 @delay(i8 %p) #0 {
>> entry:
>> tail call void asm sideeffect "inst $0,
>> $1\0A\09",
>> "=*Q,*Q"(i8*
>> @delay_count, i8* @aaa) #2, !srcloc !4
>> ret i8 undef
>> }
>>
>> notice the *Q constraints, so is there anything
>> wrong in there?
>>
>> Is there anything else that needs to be covered for
>> the
>> memory constraint?
>>
>>
>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>> <mailto:stp...@na...> <mailto:stp...@na...
>> <mailto:stp...@na...>>>
>>
>>
>> Hi Borja,
>>
>> > Stepan, reply in this thread to my 2
>> questions again
>> if the email
>> got lost.
>>
>> My prev. reply:
>>
>>
>> > Ahh, I didn't know avr-gcc was buggy on this
>> feature, that's probably
>> > the reason for why the code i pasted in my
>> previous
>> email didn't
>> work.
>> ...
>> > What's wrong with clang? I fixed clang
>> inline asm
>> support back on
>> > friday, so is there anything else that is
>> broken?
>> It should emit '*Q' instead of 'Q'. That's why
>> code
>> from prev. email
>> didn't work, just compare -emit-llvm -S output
>> of
>> avr-clang with
>> other backends,
>>
>> > About the getPointerRegClass function, what
>> is it
>> used for? Also,
>> please
>> > move the implementation to the cpp file
>> instead of
>> leaving it in
>> the .h.
>> Currently, it is used in registers coelescing
>> pass.
>> While being
>> registers inflating, llvm lookups all register
>> uses. If
>> it found
>> that register is used by inline-asm as memory
>> operand,
>> it requests
>> the pointer class with this method (I think
>> the largest
>> one). But
>> may be in future this method will be used in
>> more cases.
>>
>> avr-gcc has buggy implementation of memory
>> constraint,
>> that's why
>> avr-libs doesn't use it at all. We have a
>> chance to be
>> first here
>>
>> -Stepan
>>
>> Borja Ferrer wrote:
>>
>> Stepan, reply in this thread to my 2
>> questions
>> again if the
>> email got lost.
>>
>>
>> 2013/6/27 Borja Ferrer <
>> bor...@gm...
>> <mailto:bor...@gm...>
>> <mailto:bor...@gm...
>> <mailto:bor...@gm...>**>
>> <mailto:bor...@gm...
>> <mailto:bor...@gm...>
>> <mailto:bor...@gm...
>> <mailto:bor...@gm...>**>__>__>
>>
>>
>> No, your last email only says : "So,
>> can I
>> commit that memory
>> constraint patch?"
>>
>>
>> 2013/6/27 Stepan Dyatkovskiy
>> <stp...@na... <mailto:stp...@na...>
>> <mailto:stp...@na...
>> <mailto:stp...@na...>>
>> <mailto:stp...@na...
>> <mailto:stp...@na...> <mailto:stp...@na...
>> <mailto:stp...@na...>>>>
>>
>>
>>
>> Hm... Didn't you get my previous
>> mail? If
>> not, I think,
>> I have
>> to change my mail box.
>>
>> -Stepan
>>
>>
>> -------- Original Message --------
>> Subject: Re: [avr-llvm-devel]
>> Inline
>> assembly. Mostly
>> just a stub.
>> Date: Tue, 25 Jun 2013 18:30:46
>> +0400
>> From: Stepan Dyatkovskiy
>> <stp...@na... <mailto:stp...@na...>
>> <mailto:stp...@na...
>> <mailto:stp...@na...>>
>> <mailto:stp...@na...
>> <mailto:stp...@na...> <mailto:stp...@na...
>> <mailto:stp...@na...>>>>
>> To: Borja Ferrer
>> <bor...@gm...
>> <mailto:bor...@gm...>
>> <mailto:bor...@gm...
>> <mailto:bor...@gm...>**>
>> <mailto:bor...@gm...
>> <mailto:bor...@gm...>
>> <mailto:bor...@gm...
>> <mailto:bor...@gm...>**>__>__>
>> CC: avr-llvm
>> <avr-llvm-devel@lists.__source**______forge.net<http://source______forge.net>
>> <http://source____forge.net>
>> <http://source__forge.net>
>> <http://source <http://sourceforge.net>
>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-28 18:44:25
|
Hi Borja.
This is almost the final multibyte constraint patch. Tests are not
created yet.
Currently I have issue with 64 bit values. Even if I pass them as inline
asm operands, llvm still truncates them to i32.
What works:
long a; // 32 bit
void f() {
asm("instr %A0 %B0 %C0 %D0": : "r"(a));
}
What doesn't work:
long long a; // 64 bit
void f() {
asm("instr %A0 %B0 %E0": : "r"(a));
}
The last one fires assertion since llvm allocates registers for the
first 32 bits only.
-Stepan.
Borja Ferrer wrote:
> Yes fine
>
> El jueves, 27 de junio de 2013, Stepan Dyatkovskiy escribió:
>
> OK. Will do.
> Currently there is a patch with memory constraint and draft
> multibyte constraint (supports only A and B). To be clean under
> multibyte constraints I mean something like this:
> asm volatile("mov __tmp_reg__, %A0" "\n\t"
> "mov %A0, %B0" "\n\t"
> "mov %B0, __tmp_reg__" "\n\t"
> : "=r" (value)
> : "0" (value)
> );
>
> -Stepan.
> Borja Ferrer wrote:
>
> btw, if this is now feature complete you can commit it.
>
>
> 2013/6/27 Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>>
>
> No, that code is a personal modification of your examples.
> If you
> aren't getting the correct output from clang that's because you
> probably didn't apply a patch i commited last week for
> clang in our SVN.
> The assertion you're getting looks reasonable, it's an old
> friend of
> mine. The reason is that if Y is being reserved as the frame
> pointer, you cant have an instruction that uses 2 registers
> when
> only Z is available. I wouldn't mind too much about it.
>
> Now, my 2nd question:
>
> Is there anything else that needs to be covered for the memory
> constraint?
>
>
> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...>>
>
> This one looks good. Though ./llc emits "run out of
> registers
> allocation. I'll look at it. Is that from avr-libc?
> -Stepan.
> Borja Ferrer wrote:
>
> Yes, and then I replied the following:
>
> For this C code:
>
> char delay_count;
> char aaa;
> uint8_t delay(unsigned char p)
> {
> uint8_t cnt;
> asm volatile (
> "inst %0, %1" "\n\t"
> : "=Q" (delay_count)
> : "Q" (aaa));
> return cnt;
> }
>
> Clang produces:
>
> define i8 @delay(i8 %p) #0 {
> entry:
> tail call void asm sideeffect "inst $0, $1\0A\09",
> "=*Q,*Q"(i8*
> @delay_count, i8* @aaa) #2, !srcloc !4
> ret i8 undef
> }
>
> notice the *Q constraints, so is there anything
> wrong in there?
>
> Is there anything else that needs to be covered for the
> memory constraint?
>
>
> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>
>
>
> Hi Borja,
>
> > Stepan, reply in this thread to my 2
> questions again
> if the email
> got lost.
>
> My prev. reply:
>
>
> > Ahh, I didn't know avr-gcc was buggy on this
> feature, that's probably
> > the reason for why the code i pasted in my
> previous
> email didn't
> work.
> ...
> > What's wrong with clang? I fixed clang
> inline asm
> support back on
> > friday, so is there anything else that is
> broken?
> It should emit '*Q' instead of 'Q'. That's why
> code
> from prev. email
> didn't work, just compare -emit-llvm -S output of
> avr-clang with
> other backends,
>
> > About the getPointerRegClass function, what
> is it
> used for? Also,
> please
> > move the implementation to the cpp file
> instead of
> leaving it in
> the .h.
> Currently, it is used in registers coelescing
> pass.
> While being
> registers inflating, llvm lookups all register
> uses. If
> it found
> that register is used by inline-asm as memory
> operand,
> it requests
> the pointer class with this method (I think
> the largest
> one). But
> may be in future this method will be used in
> more cases.
>
> avr-gcc has buggy implementation of memory
> constraint,
> that's why
> avr-libs doesn't use it at all. We have a
> chance to be
> first here
>
> -Stepan
>
> Borja Ferrer wrote:
>
> Stepan, reply in this thread to my 2 questions
> again if the
> email got lost.
>
>
> 2013/6/27 Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>__>__>
>
>
> No, your last email only says : "So,
> can I
> commit that memory
> constraint patch?"
>
>
> 2013/6/27 Stepan Dyatkovskiy
> <stp...@na... <mailto:stp...@na...>
> <mailto:stp...@na...
> <mailto:stp...@na...>>
> <mailto:stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>>
>
>
>
> Hm... Didn't you get my previous
> mail? If
> not, I think,
> I have
> to change my mail box.
>
> -Stepan
>
>
> -------- Original Message --------
> Subject: Re: [avr-llvm-devel] Inline
> assembly. Mostly
> just a stub.
> Date: Tue, 25 Jun 2013 18:30:46 +0400
> From: Stepan Dyatkovskiy
> <stp...@na... <mailto:stp...@na...>
> <mailto:stp...@na...
> <mailto:stp...@na...>>
> <mailto:stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>>
> To: Borja Ferrer
> <bor...@gm...
> <mailto:bor...@gm...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>__>__>
> CC: avr-llvm
> <avr-llvm-devel@lists.__source______forge.net
> <http://source____forge.net>
> <http://source__forge.net>
> <http://source <http://sourceforge.net>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-27 22:32:49
|
Yes fine
El jueves, 27 de junio de 2013, Stepan Dyatkovskiy escribió:
> OK. Will do.
> Currently there is a patch with memory constraint and draft multibyte
> constraint (supports only A and B). To be clean under multibyte constraints
> I mean something like this:
> asm volatile("mov __tmp_reg__, %A0" "\n\t"
> "mov %A0, %B0" "\n\t"
> "mov %B0, __tmp_reg__" "\n\t"
> : "=r" (value)
> : "0" (value)
> );
>
> -Stepan.
> Borja Ferrer wrote:
>
>> btw, if this is now feature complete you can commit it.
>>
>>
>> 2013/6/27 Borja Ferrer <bor...@gm...
>> <mailto:bor...@gm...>>
>>
>> No, that code is a personal modification of your examples. If you
>> aren't getting the correct output from clang that's because you
>> probably didn't apply a patch i commited last week for clang in our
>> SVN.
>> The assertion you're getting looks reasonable, it's an old friend of
>> mine. The reason is that if Y is being reserved as the frame
>> pointer, you cant have an instruction that uses 2 registers when
>> only Z is available. I wouldn't mind too much about it.
>>
>> Now, my 2nd question:
>>
>> Is there anything else that needs to be covered for the memory
>> constraint?
>>
>>
>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>> <mailto:stp...@na...>>
>>
>> This one looks good. Though ./llc emits "run out of registers
>> allocation. I'll look at it. Is that from avr-libc?
>> -Stepan.
>> Borja Ferrer wrote:
>>
>> Yes, and then I replied the following:
>>
>> For this C code:
>>
>> char delay_count;
>> char aaa;
>> uint8_t delay(unsigned char p)
>> {
>> uint8_t cnt;
>> asm volatile (
>> "inst %0, %1" "\n\t"
>> : "=Q" (delay_count)
>> : "Q" (aaa));
>> return cnt;
>> }
>>
>> Clang produces:
>>
>> define i8 @delay(i8 %p) #0 {
>> entry:
>> tail call void asm sideeffect "inst $0, $1\0A\09",
>> "=*Q,*Q"(i8*
>> @delay_count, i8* @aaa) #2, !srcloc !4
>> ret i8 undef
>> }
>>
>> notice the *Q constraints, so is there anything wrong in
>> there?
>>
>> Is there anything else that needs to be covered for the
>> memory constraint?
>>
>>
>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>> <mailto:stp...@na...> <mailto:stp...@na...
>> <mailto:stp...@na...>>>
>>
>>
>> Hi Borja,
>>
>> > Stepan, reply in this thread to my 2 questions again
>> if the email
>> got lost.
>>
>> My prev. reply:
>>
>>
>> > Ahh, I didn't know avr-gcc was buggy on this
>> feature, that's probably
>> > the reason for why the code i pasted in my previous
>> email didn't
>> work.
>> ...
>> > What's wrong with clang? I fixed clang inline asm
>> support back on
>> > friday, so is there anything else that is broken?
>> It should emit '*Q' instead of 'Q'. That's why code
>> from prev. email
>> didn't work, just compare -emit-llvm -S output of
>> avr-clang with
>> other backends,
>>
>> > About the getPointerRegClass function, what is it
>> used for? Also,
>> please
>> > move the implementation to the cpp file instead of
>> leaving it in
>> the .h.
>> Currently, it is used in registers coelescing pass.
>> While being
>> registers inflating, llvm lookups all register uses. If
>> it found
>> that register is used by inline-asm as memory operand,
>> it requests
>> the pointer class with this method (I think the largest
>> one). But
>> may be in future this method will be used in more cases.
>>
>> avr-gcc has buggy implementation of memory constraint,
>> that's why
>> avr-libs doesn't use it at all. We have a chance to be
>> first here
>>
>> -Stepan
>>
>> Borja Ferrer wrote:
>>
>> Stepan, reply in this thread to my 2 questions
>> again if the
>> email got lost.
>>
>>
>> 2013/6/27 Borja Ferrer <bor...@gm...
>> <mailto:bor...@gm...>
>> <mailto:bor...@gm...
>> <mailto:bor...@gm...>>
>> <mailto:bor...@gm...
>> <mailto:bor...@gm...> <mailto:bor...@gm...
>> <mailto:bor...@gm...>>__>__>
>>
>>
>> No, your last email only says : "So, can I
>> commit that memory
>> constraint patch?"
>>
>>
>> 2013/6/27 Stepan Dyatkovskiy
>> <stp...@na... <mailto:stp...@na...>
>> <mailto:stp...@na... <mailto:stp...@na...
>> >>
>> <mailto:stp...@na...
>> <mailto:stp...@na...> <mailto:stp...@na...
>> <mailto:stp...@na...>>>>
>>
>>
>>
>> Hm... Didn't you get my previous mail? If
>> not, I think,
>> I have
>> to change my mail box.
>>
>> -Stepan
>>
>>
>> -------- Original Message --------
>> Subject: Re: [avr-llvm-devel] Inline
>> assembly. Mostly
>> just a stub.
>> Date: Tue, 25 Jun 2013 18:30:46 +0400
>> From: Stepan Dyatkovskiy
>> <stp...@na... <mailto:stp...@na...>
>> <mailto:stp...@na... <mailto:stp...@na...
>> >>
>> <mailto:stp...@na...
>> <mailto:stp...@na...> <mailto:stp...@na...
>> <mailto:stp...@na...>>>>
>> To: Borja Ferrer <bor...@gm...
>> <mailto:bor...@gm...>
>> <mailto:bor...@gm...
>> <mailto:bor...@gm...>>
>> <mailto:bor...@gm...
>> <mailto:bor...@gm...>
>> <mailto:bor...@gm...
>> <mailto:bor...@gm...>>__>__>
>> CC: avr-llvm
>> <avr-llvm-devel@lists.__source**____forge.net<http://source____forge.net>
>> <http://source__forge.net>
>> <http://source <http://sourceforge.net>
>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-27 19:03:12
|
OK. Will do.
Currently there is a patch with memory constraint and draft multibyte
constraint (supports only A and B). To be clean under multibyte
constraints I mean something like this:
asm volatile("mov __tmp_reg__, %A0" "\n\t"
"mov %A0, %B0" "\n\t"
"mov %B0, __tmp_reg__" "\n\t"
: "=r" (value)
: "0" (value)
);
-Stepan.
Borja Ferrer wrote:
> btw, if this is now feature complete you can commit it.
>
>
> 2013/6/27 Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>>
>
> No, that code is a personal modification of your examples. If you
> aren't getting the correct output from clang that's because you
> probably didn't apply a patch i commited last week for clang in our SVN.
> The assertion you're getting looks reasonable, it's an old friend of
> mine. The reason is that if Y is being reserved as the frame
> pointer, you cant have an instruction that uses 2 registers when
> only Z is available. I wouldn't mind too much about it.
>
> Now, my 2nd question:
>
> Is there anything else that needs to be covered for the memory
> constraint?
>
>
> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...>>
>
> This one looks good. Though ./llc emits "run out of registers
> allocation. I'll look at it. Is that from avr-libc?
> -Stepan.
> Borja Ferrer wrote:
>
> Yes, and then I replied the following:
>
> For this C code:
>
> char delay_count;
> char aaa;
> uint8_t delay(unsigned char p)
> {
> uint8_t cnt;
> asm volatile (
> "inst %0, %1" "\n\t"
> : "=Q" (delay_count)
> : "Q" (aaa));
> return cnt;
> }
>
> Clang produces:
>
> define i8 @delay(i8 %p) #0 {
> entry:
> tail call void asm sideeffect "inst $0, $1\0A\09",
> "=*Q,*Q"(i8*
> @delay_count, i8* @aaa) #2, !srcloc !4
> ret i8 undef
> }
>
> notice the *Q constraints, so is there anything wrong in there?
>
> Is there anything else that needs to be covered for the
> memory constraint?
>
>
> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>
>
>
> Hi Borja,
>
> > Stepan, reply in this thread to my 2 questions again
> if the email
> got lost.
>
> My prev. reply:
>
>
> > Ahh, I didn't know avr-gcc was buggy on this
> feature, that's probably
> > the reason for why the code i pasted in my previous
> email didn't
> work.
> ...
> > What's wrong with clang? I fixed clang inline asm
> support back on
> > friday, so is there anything else that is broken?
> It should emit '*Q' instead of 'Q'. That's why code
> from prev. email
> didn't work, just compare -emit-llvm -S output of
> avr-clang with
> other backends,
>
> > About the getPointerRegClass function, what is it
> used for? Also,
> please
> > move the implementation to the cpp file instead of
> leaving it in
> the .h.
> Currently, it is used in registers coelescing pass.
> While being
> registers inflating, llvm lookups all register uses. If
> it found
> that register is used by inline-asm as memory operand,
> it requests
> the pointer class with this method (I think the largest
> one). But
> may be in future this method will be used in more cases.
>
> avr-gcc has buggy implementation of memory constraint,
> that's why
> avr-libs doesn't use it at all. We have a chance to be
> first here
>
> -Stepan
>
> Borja Ferrer wrote:
>
> Stepan, reply in this thread to my 2 questions
> again if the
> email got lost.
>
>
> 2013/6/27 Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>
> <mailto:bor...@gm...
> <mailto:bor...@gm...> <mailto:bor...@gm...
> <mailto:bor...@gm...>>__>__>
>
>
> No, your last email only says : "So, can I
> commit that memory
> constraint patch?"
>
>
> 2013/6/27 Stepan Dyatkovskiy
> <stp...@na... <mailto:stp...@na...>
> <mailto:stp...@na... <mailto:stp...@na...>>
> <mailto:stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>>
>
>
>
> Hm... Didn't you get my previous mail? If
> not, I think,
> I have
> to change my mail box.
>
> -Stepan
>
>
> -------- Original Message --------
> Subject: Re: [avr-llvm-devel] Inline
> assembly. Mostly
> just a stub.
> Date: Tue, 25 Jun 2013 18:30:46 +0400
> From: Stepan Dyatkovskiy
> <stp...@na... <mailto:stp...@na...>
> <mailto:stp...@na... <mailto:stp...@na...>>
> <mailto:stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>>
> To: Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>__>__>
> CC: avr-llvm
> <avr-llvm-devel@lists.__source____forge.net
> <http://source__forge.net>
> <http://sourceforge.net>
> <mailto:avr-llvm-devel@lists.
> <mailto:avr-llvm-devel@lists.>____sourceforge.net
> <http://sourceforge.net>
>
> <mailto:avr-llvm-devel@lists.__sourceforge.net
> <mailto:avr...@li...>>>>, John Myers
> <ato...@gm...
> <mailto:ato...@gm...>
> <mailto:atomicdog.jwm@gmail.__com
> <mailto:ato...@gm...>>
> <mailto:atomicdog.jwm@gmail.
> <mailto:atomicdog.jwm@gmail.>____com
> <mailto:atomicdog.jwm@gmail.__com
> <mailto:ato...@gm...>>>>
>
>
> Hi Borja,
>
> Ahh, I didn't know avr-gcc was buggy
> on this
> feature, that's
> probably
> the reason for why the code i pasted
> in my previous
> email
> didn't work.
>
> ...
>
> What's wrong with clang? I fixed clang
> inline asm
> support
> back on
> friday, so is there anything else that
> is broken?
>
> It should emit '*Q' instead of 'Q'. That's
> why code
> from prev. email
> didn't work, just compare -emit-llvm -S
> output of
> avr-clang with
> other
> backends,
>
> About the getPointerRegClass function,
> what is it
> used for?
> Also, please
> move the implementation to the cpp
> file instead of
> leaving
> it in the .h.
>
> Currently, it is used in registers
> coelescing pass.
> While being
> registers inflating, llvm lookups all
> register uses. If
> it found
> that
> register is used by inline-asm as memory
> operand, it
> requests the
> pointer class with this method (I think
> the largest
> one). But
> may be in
> future this method will be used in more cases.
>
> avr-gcc has buggy implementation of memory
> constraint,
> that's why
> avr-libs doesn't use it at all. We have a
> chance to be
> first
> here :-)
>
> -Stepan
>
>
>
>
> 2013/6/25 Stepan Dyatkovskiy
> <stp...@na... <mailto:stp...@na...>
> <mailto:stp...@na... <mailto:stp...@na...>>
> <mailto:stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na...
> <mailto:stp...@na...>>> <mailto:stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na... <mailto:stp...@na...>>
>
> <mailto:stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>>>
>
>
> Hi Borja.
> This is new patch. Seems I've
> moved memory
> constraint
> implementation
> to the same level like all other
> constraints. Note
> avr-gcc has buggy
> implementation of memory
> constraint, that's why
> *avr-libc doesn't
> use it*.
>
> I removed restriction for Y,Z in
> getLargestLegalSuperClass, so these
> registers could be inflated now.
> But there was
> unimplemented
> getPointerRegClass method in
> AVRRegistersInfo. So
> currently I have
> restricted it to Y and Z. Though
> suppose we
> can extend
> it in future
> to XYZ set.
> Look changes in inline-asm.ll to
> see what
> exactly is
> supported now.
>
> About clang.
> May be we ask John Myers to fix
> clang support for
> inline asm?
>
> -Stepan.
>
>
> Stepan Dyatkovskiy wrote:
>
> The patch. Forgot to attach it.
> -Stepan.
> Stepan Dyatkovskiy wrote:
>
> Hi Borja,
>
> > What happens in your
> example above
> when you
> use a real
> instruction
> like
>
> for example LDD? Does
> it still use
> GPR8
> regs? To me it's
> weird that if
> you use a real
> instruction where
> operands
> are clearly
> defined in the td
> file the instruction
> selector uses an
> invalid regclass.
>
>
> There are two kinds of
> inline asm
> support in LLVM:
> 1. You just support all the
> constraints and pastes
> inline-asm contents
> as-is. That's why its
> still allowed to use
> names like
> "some_instr".
> 2. You may expand
> inline-asm strings
> set, or in
> another
> words just parse
> it onto set of
> instructions. In this
> case you
> have to implement
>
> TargetLowering::________ExpandInlineAsm
>
> method.
>
> I'd want to start it on
> this week
> though...
>
> But first we have to get
> avr-libc
> compilable
> (perhpas I read you
> thoughts ;-) )
>
> Relative to memory
> constrains. I
> implemented
> initial version
> it can
> catch simplest cases
> (from test-case):
>
> @a = internal global i16
> 0, align 4
> @b = internal global i16
> 0, align 4
> define void @mem() {
> ;CHECK: some_instr Z, Y
> call void asm
> "some_instr $0, $1",
> "=*Q,=*Q"(i16* @a,
> i16* @b)
> ret void
> }
>
> The patch is attached.
>
> Its in my todo yet, to
> handle local
> variables.
> They could be
> emitted as
> Y+q expression. Hope to
> present this
> support
> tomorrow. So if
> 'a' and 'b'
> from example above would
> be local we
> could get
> "some_instr
> Y, Y+2"
>
> -Stepan.
>
>
>
>
>
>
>
>
>
>
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-27 18:47:49
|
btw, if this is now feature complete you can commit it.
2013/6/27 Borja Ferrer <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...>
>
>> This one looks good. Though ./llc emits "run out of registers allocation.
>> I'll look at it. Is that from avr-libc?
>> -Stepan.
>> Borja Ferrer wrote:
>>
>>> Yes, and then I replied the following:
>>>
>>> For this C code:
>>>
>>> char delay_count;
>>> char aaa;
>>> uint8_t delay(unsigned char p)
>>> {
>>> uint8_t cnt;
>>> asm volatile (
>>> "inst %0, %1" "\n\t"
>>> : "=Q" (delay_count)
>>> : "Q" (aaa));
>>> return cnt;
>>> }
>>>
>>> Clang produces:
>>>
>>> define i8 @delay(i8 %p) #0 {
>>> entry:
>>> tail call void asm sideeffect "inst $0, $1\0A\09", "=*Q,*Q"(i8*
>>> @delay_count, i8* @aaa) #2, !srcloc !4
>>> ret i8 undef
>>> }
>>>
>>> notice the *Q constraints, so is there anything wrong in there?
>>>
>>> Is there anything else that needs to be covered for the memory
>>> constraint?
>>>
>>>
>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na... <mailto:
>>> stp...@na...>>
>>>
>>>
>>> Hi Borja,
>>>
>>> > Stepan, reply in this thread to my 2 questions again if the email
>>> got lost.
>>>
>>> My prev. reply:
>>>
>>>
>>> > Ahh, I didn't know avr-gcc was buggy on this feature, that's
>>> probably
>>> > the reason for why the code i pasted in my previous email didn't
>>> work.
>>> ...
>>> > What's wrong with clang? I fixed clang inline asm support back on
>>> > friday, so is there anything else that is broken?
>>> It should emit '*Q' instead of 'Q'. That's why code from prev. email
>>> didn't work, just compare -emit-llvm -S output of avr-clang with
>>> other backends,
>>>
>>> > About the getPointerRegClass function, what is it used for? Also,
>>> please
>>> > move the implementation to the cpp file instead of leaving it in
>>> the .h.
>>> Currently, it is used in registers coelescing pass. While being
>>> registers inflating, llvm lookups all register uses. If it found
>>> that register is used by inline-asm as memory operand, it requests
>>> the pointer class with this method (I think the largest one). But
>>> may be in future this method will be used in more cases.
>>>
>>> avr-gcc has buggy implementation of memory constraint, that's why
>>> avr-libs doesn't use it at all. We have a chance to be first here
>>>
>>> -Stepan
>>>
>>> Borja Ferrer wrote:
>>>
>>> Stepan, reply in this thread to my 2 questions again if the
>>> email got lost.
>>>
>>>
>>> 2013/6/27 Borja Ferrer <bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm... <mailto:bor...@gm...>**
>>> >__>
>>>
>>>
>>> No, your last email only says : "So, can I commit that
>>> memory
>>> constraint patch?"
>>>
>>>
>>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>>> <mailto:stp...@na...>
>>> <mailto:stp...@na... <mailto:stp...@na...>>>
>>>
>>>
>>>
>>> Hm... Didn't you get my previous mail? If not, I think,
>>> I have
>>> to change my mail box.
>>>
>>> -Stepan
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: [avr-llvm-devel] Inline assembly. Mostly
>>> just a stub.
>>> Date: Tue, 25 Jun 2013 18:30:46 +0400
>>> From: Stepan Dyatkovskiy <stp...@na...
>>> <mailto:stp...@na...>
>>> <mailto:stp...@na... <mailto:stp...@na...>>>
>>> To: Borja Ferrer <bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>__>
>>> CC: avr-llvm <avr-llvm-devel@lists.__source**
>>> __forge.net <http://source__forge.net>
>>> <http://sourceforge.net>
>>> <mailto:avr-llvm-devel@lists._**_sourceforge.net
>>>
>>> <mailto:avr-llvm-devel@lists.**sourceforge.net<avr...@li...>>>>,
>>> John Myers
>>> <ato...@gm...
>>> <mailto:atomicdog.jwm@gmail.**com <ato...@gm...>>
>>> <mailto:atomicdog.jwm@gmail.__**com <mailto:atomicdog.jwm@gmail.
>>> **com <ato...@gm...>>>>
>>>
>>>
>>> Hi Borja,
>>>
>>> Ahh, I didn't know avr-gcc was buggy on this
>>> feature, that's
>>> probably
>>> the reason for why the code i pasted in my previous
>>> email
>>> didn't work.
>>>
>>> ...
>>>
>>> What's wrong with clang? I fixed clang inline asm
>>> support
>>> back on
>>> friday, so is there anything else that is broken?
>>>
>>> It should emit '*Q' instead of 'Q'. That's why code
>>> from prev. email
>>> didn't work, just compare -emit-llvm -S output of
>>> avr-clang with
>>> other
>>> backends,
>>>
>>> About the getPointerRegClass function, what is it
>>> used for?
>>> Also, please
>>> move the implementation to the cpp file instead of
>>> leaving
>>> it in the .h.
>>>
>>> Currently, it is used in registers coelescing pass.
>>> While being
>>> registers inflating, llvm lookups all register uses. If
>>> it found
>>> that
>>> register is used by inline-asm as memory operand, it
>>> requests the
>>> pointer class with this method (I think the largest
>>> one). But
>>> may be in
>>> future this method will be used in more cases.
>>>
>>> avr-gcc has buggy implementation of memory constraint,
>>> that's why
>>> avr-libs doesn't use it at all. We have a chance to be
>>> first
>>> here :-)
>>>
>>> -Stepan
>>>
>>>
>>>
>>>
>>> 2013/6/25 Stepan Dyatkovskiy <stp...@na...
>>> <mailto:stp...@na...>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...>> <mailto:stp...@na...
>>> <mailto:stp...@na...>
>>>
>>> <mailto:stp...@na... <mailto:stp...@na...
>>> >>>>
>>>
>>>
>>> Hi Borja.
>>> This is new patch. Seems I've moved memory
>>> constraint
>>> implementation
>>> to the same level like all other constraints.
>>> Note
>>> avr-gcc has buggy
>>> implementation of memory constraint, that's why
>>> *avr-libc doesn't
>>> use it*.
>>>
>>> I removed restriction for Y,Z in
>>> getLargestLegalSuperClass, so these
>>> registers could be inflated now. But there was
>>> unimplemented
>>> getPointerRegClass method in AVRRegistersInfo.
>>> So
>>> currently I have
>>> restricted it to Y and Z. Though suppose we
>>> can extend
>>> it in future
>>> to XYZ set.
>>> Look changes in inline-asm.ll to see what
>>> exactly is
>>> supported now.
>>>
>>> About clang.
>>> May be we ask John Myers to fix clang support
>>> for
>>> inline asm?
>>>
>>> -Stepan.
>>>
>>>
>>> Stepan Dyatkovskiy wrote:
>>>
>>> The patch. Forgot to attach it.
>>> -Stepan.
>>> Stepan Dyatkovskiy wrote:
>>>
>>> Hi Borja,
>>>
>>> > What happens in your example above
>>> when you
>>> use a real
>>> instruction
>>> like
>>>
>>> for example LDD? Does it still use
>>> GPR8
>>> regs? To me it's
>>> weird that if
>>> you use a real instruction where
>>> operands
>>> are clearly
>>> defined in the td
>>> file the instruction selector uses
>>> an
>>> invalid regclass.
>>>
>>>
>>> There are two kinds of inline asm
>>> support in LLVM:
>>> 1. You just support all the
>>> constraints and pastes
>>> inline-asm contents
>>> as-is. That's why its still allowed to
>>> use
>>> names like
>>> "some_instr".
>>> 2. You may expand inline-asm strings
>>> set, or in
>>> another
>>> words just parse
>>> it onto set of instructions. In this
>>> case you
>>> have to implement
>>> TargetLowering::______**
>>> ExpandInlineAsm
>>>
>>> method.
>>>
>>> I'd want to start it on this week
>>> though...
>>>
>>> But first we have to get avr-libc
>>> compilable
>>> (perhpas I read you
>>> thoughts ;-) )
>>>
>>> Relative to memory constrains. I
>>> implemented
>>> initial version
>>> it can
>>> catch simplest cases (from test-case):
>>>
>>> @a = internal global i16 0, align 4
>>> @b = internal global i16 0, align 4
>>> define void @mem() {
>>> ;CHECK: some_instr Z, Y
>>> call void asm "some_instr $0, $1",
>>> "=*Q,=*Q"(i16* @a,
>>> i16* @b)
>>> ret void
>>> }
>>>
>>> The patch is attached.
>>>
>>> Its in my todo yet, to handle local
>>> variables.
>>> They could be
>>> emitted as
>>> Y+q expression. Hope to present this
>>> support
>>> tomorrow. So if
>>> 'a' and 'b'
>>> from example above would be local we
>>> could get
>>> "some_instr
>>> Y, Y+2"
>>>
>>> -Stepan.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-27 18:04:52
|
Ok, remember that there's an additional constraint to print memory
registers as X, Y, Z instead of r26, etc... it's described in the avr libc
manual. This one should be easier than the multi byte constraints.
2013/6/27 Stepan Dyatkovskiy <stp...@na...>
> Good ) Currently I'm working on multi-byte constraints. Once it would be
> done, hope we can compile avr-libc.
>
> -Stepan.
>
> Borja Ferrer wrote:
>
>> 1) I think this now resolved.
>> 2) I will take a look, no idea about it now.
>>
>>
>> 2013/6/27 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...
>> >>
>>
>>
>> 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<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.__sourcef**orge.net<http://sourceforge.net>
>> <mailto: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> <
>> 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-27 18:01:28
|
Good ) Currently I'm working on multi-byte constraints. Once it would be
done, hope we can compile avr-libc.
-Stepan.
Borja Ferrer wrote:
> 1) I think this now resolved.
> 2) I will take a look, no idea about it now.
>
>
> 2013/6/27 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>>
>
> 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
> <http://p.sf.net/sfu/windows-dev2dev>
> _________________________________________________
> avr-llvm-devel mailing list
> 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>
>
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-27 17:57:03
|
1) I think this now resolved.
2) I will take a look, no idea about it now.
2013/6/27 Stepan Dyatkovskiy <stp...@na...>
> 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<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: Borja F. <bor...@gm...> - 2013-06-27 17:55:37
|
No, that code is a personal modification of your examples. If you aren't
getting the correct output from clang that's because you probably didn't
apply a patch i commited last week for clang in our SVN.
The assertion you're getting looks reasonable, it's an old friend of mine.
The reason is that if Y is being reserved as the frame pointer, you cant
have an instruction that uses 2 registers when only Z is available. I
wouldn't mind too much about it.
Now, my 2nd question:
Is there anything else that needs to be covered for the memory constraint?
2013/6/27 Stepan Dyatkovskiy <stp...@na...>
> This one looks good. Though ./llc emits "run out of registers allocation.
> I'll look at it. Is that from avr-libc?
> -Stepan.
> Borja Ferrer wrote:
>
>> Yes, and then I replied the following:
>>
>> For this C code:
>>
>> char delay_count;
>> char aaa;
>> uint8_t delay(unsigned char p)
>> {
>> uint8_t cnt;
>> asm volatile (
>> "inst %0, %1" "\n\t"
>> : "=Q" (delay_count)
>> : "Q" (aaa));
>> return cnt;
>> }
>>
>> Clang produces:
>>
>> define i8 @delay(i8 %p) #0 {
>> entry:
>> tail call void asm sideeffect "inst $0, $1\0A\09", "=*Q,*Q"(i8*
>> @delay_count, i8* @aaa) #2, !srcloc !4
>> ret i8 undef
>> }
>>
>> notice the *Q constraints, so is there anything wrong in there?
>>
>> Is there anything else that needs to be covered for the memory constraint?
>>
>>
>> 2013/6/27 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...
>> >>
>>
>>
>> Hi Borja,
>>
>> > Stepan, reply in this thread to my 2 questions again if the email
>> got lost.
>>
>> My prev. reply:
>>
>>
>> > Ahh, I didn't know avr-gcc was buggy on this feature, that's
>> probably
>> > the reason for why the code i pasted in my previous email didn't
>> work.
>> ...
>> > What's wrong with clang? I fixed clang inline asm support back on
>> > friday, so is there anything else that is broken?
>> It should emit '*Q' instead of 'Q'. That's why code from prev. email
>> didn't work, just compare -emit-llvm -S output of avr-clang with
>> other backends,
>>
>> > About the getPointerRegClass function, what is it used for? Also,
>> please
>> > move the implementation to the cpp file instead of leaving it in
>> the .h.
>> Currently, it is used in registers coelescing pass. While being
>> registers inflating, llvm lookups all register uses. If it found
>> that register is used by inline-asm as memory operand, it requests
>> the pointer class with this method (I think the largest one). But
>> may be in future this method will be used in more cases.
>>
>> avr-gcc has buggy implementation of memory constraint, that's why
>> avr-libs doesn't use it at all. We have a chance to be first here
>>
>> -Stepan
>>
>> Borja Ferrer wrote:
>>
>> Stepan, reply in this thread to my 2 questions again if the
>> email got lost.
>>
>>
>> 2013/6/27 Borja Ferrer <bor...@gm...
>> <mailto:bor...@gm...>
>> <mailto:bor...@gm... <mailto:bor...@gm...>**
>> >__>
>>
>>
>> No, your last email only says : "So, can I commit that memory
>> constraint patch?"
>>
>>
>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>> <mailto:stp...@na...>
>> <mailto:stp...@na... <mailto:stp...@na...>>>
>>
>>
>>
>> Hm... Didn't you get my previous mail? If not, I think,
>> I have
>> to change my mail box.
>>
>> -Stepan
>>
>>
>> -------- Original Message --------
>> Subject: Re: [avr-llvm-devel] Inline assembly. Mostly
>> just a stub.
>> Date: Tue, 25 Jun 2013 18:30:46 +0400
>> From: Stepan Dyatkovskiy <stp...@na...
>> <mailto:stp...@na...>
>> <mailto:stp...@na... <mailto:stp...@na...>>>
>> To: Borja Ferrer <bor...@gm...
>> <mailto:bor...@gm...>
>> <mailto:bor...@gm...
>> <mailto:bor...@gm...>**>__>
>> CC: avr-llvm <avr-llvm-devel@lists.__source**__forge.net<http://source__forge.net>
>> <http://sourceforge.net>
>> <mailto:avr-llvm-devel@lists._**_sourceforge.net
>>
>> <mailto:avr-llvm-devel@lists.**sourceforge.net<avr...@li...>>>>,
>> John Myers
>> <ato...@gm...
>> <mailto:atomicdog.jwm@gmail.**com <ato...@gm...>>
>> <mailto:atomicdog.jwm@gmail.__**com <mailto:atomicdog.jwm@gmail.*
>> *com <ato...@gm...>>>>
>>
>>
>> Hi Borja,
>>
>> Ahh, I didn't know avr-gcc was buggy on this
>> feature, that's
>> probably
>> the reason for why the code i pasted in my previous
>> email
>> didn't work.
>>
>> ...
>>
>> What's wrong with clang? I fixed clang inline asm
>> support
>> back on
>> friday, so is there anything else that is broken?
>>
>> It should emit '*Q' instead of 'Q'. That's why code
>> from prev. email
>> didn't work, just compare -emit-llvm -S output of
>> avr-clang with
>> other
>> backends,
>>
>> About the getPointerRegClass function, what is it
>> used for?
>> Also, please
>> move the implementation to the cpp file instead of
>> leaving
>> it in the .h.
>>
>> Currently, it is used in registers coelescing pass.
>> While being
>> registers inflating, llvm lookups all register uses. If
>> it found
>> that
>> register is used by inline-asm as memory operand, it
>> requests the
>> pointer class with this method (I think the largest
>> one). But
>> may be in
>> future this method will be used in more cases.
>>
>> avr-gcc has buggy implementation of memory constraint,
>> that's why
>> avr-libs doesn't use it at all. We have a chance to be
>> first
>> here :-)
>>
>> -Stepan
>>
>>
>>
>>
>> 2013/6/25 Stepan Dyatkovskiy <stp...@na...
>> <mailto:stp...@na...>
>> <mailto:stp...@na...
>> <mailto:stp...@na...>> <mailto:stp...@na...
>> <mailto:stp...@na...>
>>
>> <mailto:stp...@na... <mailto:stp...@na...
>> >>>>
>>
>>
>> Hi Borja.
>> This is new patch. Seems I've moved memory
>> constraint
>> implementation
>> to the same level like all other constraints.
>> Note
>> avr-gcc has buggy
>> implementation of memory constraint, that's why
>> *avr-libc doesn't
>> use it*.
>>
>> I removed restriction for Y,Z in
>> getLargestLegalSuperClass, so these
>> registers could be inflated now. But there was
>> unimplemented
>> getPointerRegClass method in AVRRegistersInfo.
>> So
>> currently I have
>> restricted it to Y and Z. Though suppose we
>> can extend
>> it in future
>> to XYZ set.
>> Look changes in inline-asm.ll to see what
>> exactly is
>> supported now.
>>
>> About clang.
>> May be we ask John Myers to fix clang support
>> for
>> inline asm?
>>
>> -Stepan.
>>
>>
>> Stepan Dyatkovskiy wrote:
>>
>> The patch. Forgot to attach it.
>> -Stepan.
>> Stepan Dyatkovskiy wrote:
>>
>> Hi Borja,
>>
>> > What happens in your example above
>> when you
>> use a real
>> instruction
>> like
>>
>> for example LDD? Does it still use
>> GPR8
>> regs? To me it's
>> weird that if
>> you use a real instruction where
>> operands
>> are clearly
>> defined in the td
>> file the instruction selector uses
>> an
>> invalid regclass.
>>
>>
>> There are two kinds of inline asm
>> support in LLVM:
>> 1. You just support all the
>> constraints and pastes
>> inline-asm contents
>> as-is. That's why its still allowed to
>> use
>> names like
>> "some_instr".
>> 2. You may expand inline-asm strings
>> set, or in
>> another
>> words just parse
>> it onto set of instructions. In this
>> case you
>> have to implement
>> TargetLowering::______**ExpandInlineAsm
>>
>> method.
>>
>> I'd want to start it on this week
>> though...
>>
>> But first we have to get avr-libc
>> compilable
>> (perhpas I read you
>> thoughts ;-) )
>>
>> Relative to memory constrains. I
>> implemented
>> initial version
>> it can
>> catch simplest cases (from test-case):
>>
>> @a = internal global i16 0, align 4
>> @b = internal global i16 0, align 4
>> define void @mem() {
>> ;CHECK: some_instr Z, Y
>> call void asm "some_instr $0, $1",
>> "=*Q,=*Q"(i16* @a,
>> i16* @b)
>> ret void
>> }
>>
>> The patch is attached.
>>
>> Its in my todo yet, to handle local
>> variables.
>> They could be
>> emitted as
>> Y+q expression. Hope to present this
>> support
>> tomorrow. So if
>> 'a' and 'b'
>> from example above would be local we
>> could get
>> "some_instr
>> Y, Y+2"
>>
>> -Stepan.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-27 17:45:30
|
This one looks good. Though ./llc emits "run out of registers
allocation. I'll look at it. Is that from avr-libc?
-Stepan.
Borja Ferrer wrote:
> Yes, and then I replied the following:
>
> For this C code:
>
> char delay_count;
> char aaa;
> uint8_t delay(unsigned char p)
> {
> uint8_t cnt;
> asm volatile (
> "inst %0, %1" "\n\t"
> : "=Q" (delay_count)
> : "Q" (aaa));
> return cnt;
> }
>
> Clang produces:
>
> define i8 @delay(i8 %p) #0 {
> entry:
> tail call void asm sideeffect "inst $0, $1\0A\09", "=*Q,*Q"(i8*
> @delay_count, i8* @aaa) #2, !srcloc !4
> ret i8 undef
> }
>
> notice the *Q constraints, so is there anything wrong in there?
>
> Is there anything else that needs to be covered for the memory constraint?
>
>
> 2013/6/27 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>>
>
> Hi Borja,
>
> > Stepan, reply in this thread to my 2 questions again if the email
> got lost.
>
> My prev. reply:
>
>
> > Ahh, I didn't know avr-gcc was buggy on this feature, that's probably
> > the reason for why the code i pasted in my previous email didn't
> work.
> ...
> > What's wrong with clang? I fixed clang inline asm support back on
> > friday, so is there anything else that is broken?
> It should emit '*Q' instead of 'Q'. That's why code from prev. email
> didn't work, just compare -emit-llvm -S output of avr-clang with
> other backends,
>
> > About the getPointerRegClass function, what is it used for? Also,
> please
> > move the implementation to the cpp file instead of leaving it in
> the .h.
> Currently, it is used in registers coelescing pass. While being
> registers inflating, llvm lookups all register uses. If it found
> that register is used by inline-asm as memory operand, it requests
> the pointer class with this method (I think the largest one). But
> may be in future this method will be used in more cases.
>
> avr-gcc has buggy implementation of memory constraint, that's why
> avr-libs doesn't use it at all. We have a chance to be first here
>
> -Stepan
>
> Borja Ferrer wrote:
>
> Stepan, reply in this thread to my 2 questions again if the
> email got lost.
>
>
> 2013/6/27 Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>
> <mailto:bor...@gm... <mailto:bor...@gm...>>__>
>
>
> No, your last email only says : "So, can I commit that memory
> constraint patch?"
>
>
> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na... <mailto:stp...@na...>>>
>
>
> Hm... Didn't you get my previous mail? If not, I think,
> I have
> to change my mail box.
>
> -Stepan
>
>
> -------- Original Message --------
> Subject: Re: [avr-llvm-devel] Inline assembly. Mostly
> just a stub.
> Date: Tue, 25 Jun 2013 18:30:46 +0400
> From: Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na... <mailto:stp...@na...>>>
> To: Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>__>
> CC: avr-llvm <avr-llvm-devel@lists.__source__forge.net
> <http://sourceforge.net>
> <mailto:avr-llvm-devel@lists.__sourceforge.net
> <mailto:avr...@li...>>>, John Myers
> <ato...@gm...
> <mailto:ato...@gm...>
> <mailto:atomicdog.jwm@gmail.__com <mailto:ato...@gm...>>>
>
> Hi Borja,
>
> Ahh, I didn't know avr-gcc was buggy on this
> feature, that's
> probably
> the reason for why the code i pasted in my previous
> email
> didn't work.
>
> ...
>
> What's wrong with clang? I fixed clang inline asm
> support
> back on
> friday, so is there anything else that is broken?
>
> It should emit '*Q' instead of 'Q'. That's why code
> from prev. email
> didn't work, just compare -emit-llvm -S output of
> avr-clang with
> other
> backends,
>
> About the getPointerRegClass function, what is it
> used for?
> Also, please
> move the implementation to the cpp file instead of
> leaving
> it in the .h.
>
> Currently, it is used in registers coelescing pass.
> While being
> registers inflating, llvm lookups all register uses. If
> it found
> that
> register is used by inline-asm as memory operand, it
> requests the
> pointer class with this method (I think the largest
> one). But
> may be in
> future this method will be used in more cases.
>
> avr-gcc has buggy implementation of memory constraint,
> that's why
> avr-libs doesn't use it at all. We have a chance to be
> first
> here :-)
>
> -Stepan
>
>
>
>
> 2013/6/25 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na...
> <mailto:stp...@na...>> <mailto:stp...@na...
> <mailto:stp...@na...>
>
> <mailto:stp...@na... <mailto:stp...@na...>>>>
>
> Hi Borja.
> This is new patch. Seems I've moved memory
> constraint
> implementation
> to the same level like all other constraints. Note
> avr-gcc has buggy
> implementation of memory constraint, that's why
> *avr-libc doesn't
> use it*.
>
> I removed restriction for Y,Z in
> getLargestLegalSuperClass, so these
> registers could be inflated now. But there was
> unimplemented
> getPointerRegClass method in AVRRegistersInfo. So
> currently I have
> restricted it to Y and Z. Though suppose we
> can extend
> it in future
> to XYZ set.
> Look changes in inline-asm.ll to see what
> exactly is
> supported now.
>
> About clang.
> May be we ask John Myers to fix clang support for
> inline asm?
>
> -Stepan.
>
>
> Stepan Dyatkovskiy wrote:
>
> The patch. Forgot to attach it.
> -Stepan.
> Stepan Dyatkovskiy wrote:
>
> Hi Borja,
>
> > What happens in your example above
> when you
> use a real
> instruction
> like
>
> for example LDD? Does it still use
> GPR8
> regs? To me it's
> weird that if
> you use a real instruction where
> operands
> are clearly
> defined in the td
> file the instruction selector uses an
> invalid regclass.
>
>
> There are two kinds of inline asm
> support in LLVM:
> 1. You just support all the
> constraints and pastes
> inline-asm contents
> as-is. That's why its still allowed to use
> names like
> "some_instr".
> 2. You may expand inline-asm strings
> set, or in
> another
> words just parse
> it onto set of instructions. In this
> case you
> have to implement
> TargetLowering::______ExpandInlineAsm
> method.
>
> I'd want to start it on this week
> though...
>
> But first we have to get avr-libc
> compilable
> (perhpas I read you
> thoughts ;-) )
>
> Relative to memory constrains. I
> implemented
> initial version
> it can
> catch simplest cases (from test-case):
>
> @a = internal global i16 0, align 4
> @b = internal global i16 0, align 4
> define void @mem() {
> ;CHECK: some_instr Z, Y
> call void asm "some_instr $0, $1",
> "=*Q,=*Q"(i16* @a,
> i16* @b)
> ret void
> }
>
> The patch is attached.
>
> Its in my todo yet, to handle local
> variables.
> They could be
> emitted as
> Y+q expression. Hope to present this
> support
> tomorrow. So if
> 'a' and 'b'
> from example above would be local we
> could get
> "some_instr
> Y, Y+2"
>
> -Stepan.
>
>
>
>
>
>
>
>
>
>
|
14 messages has been excluded from this view by a project administrator.
