Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly. Mostly just a stub.
|
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...>
>
>
|
