Menu
▾
▴
avr-llvm-devel
|
From: Stepan D. <stp...@na...> - 2013-06-21 17:49:40
Attachments:
avr-inline-asm-mem-2013-06-21.patch
|
Hi all,
I've made the skeleton for memory constraint. Though, currently its not
clean to me how to force use of PTRDISPREGS class.
Currently two issues are opened here:
1. Clang front-end:
For input:
static int b;
void f()
{
int a;
asm("instr %0": "=Q"(b):);
}
it should produce (with -S -emit-llvm flags):
call void asm "some_instr $0", "=*Q"(i16* @b)
While now it produces:
%0 = call i16 asm "instr $0", "=Q"()
2. Currently it uses GPR8 pairs class, I'm not sure where it is better
to force PTRDISPREGS. So, currently for .ll line:
; some stuff above
call void asm "some_instr $0", "=*Q"(i16* @b)
; some stuff below
I have llc output:
.file "inline-asm-mem.ll"
.text
.globl memory
.align 2
.type memory,@function
memory: ; @memory
; BB#0:
ldi r24, lo8(b)
ldi r25, hi8(b)
;APP
some_instr [r24]
;NO_APP
ret
.Ltmp0:
.size memory, .Ltmp0-memory
.type b,@object ; @b
.local b
.comm b,2,4
Current state is applied as patch.
-Stepan.
Borja Ferrer wrote:
> 1) Ok I understand now your point. It's a valid hack for now.
> 2) I see, I've done some tests and it works as expected so no more worries.
>
> I've been testing some complex inline asm from avr libc and found the
> following things:
> 1) I was able to trigger the assertion in getRegForInlineAsmConstraint,
> I havent investigated more, but it's something that needs to be looked at.
> 2) there are some constraints to work with multi byte values (A0, B0,
> C0, etc) that dont work at all, they produce wrong code. I guess this is
> the next thing that should be implemented.
> 3) Likewise from 2) the %a0 constraint for the base pointer regs wont
> work either.
>
> One more thing, remember to commit the test cases when they're ready.
>
>
> 2013/6/20 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>>
>
> Hello Borja,
>
>
> > 1) for the M constraint you expand the type to MVT::i16 in case the
>
> value is negative. I dont understand the need to do this.
>
> By default AsmWriter treats constants as signed values. So "i8 255"
> would be printed as "i8 -1". But I'm not sure that avr-as would
> interpret this as "*i8* -1" (I even definitely sure it fails some
> code). So I'v made it i16; doing that, we can be sure that values in
> range 0..255 would be printed as unsigned.
> May be it is kind of hack, though on the first stage I'd just make
> things working...
>
>
> 2) did you manage to understand how the G constraint works? I
> see you
> return a 0 MVT::i8 constant, but floats are 32 bits so how does this
> really work.
>
> IMHO, kind of stupid constraint. avr-gcc doesn't eat .c inline asm
> string like below:
>
> 'asm("instr %0"::"G"(0.1) );'
>
> avr-gcc exits with error: impossible constraint in ‘asm’
>
> while 'asm("instr %0"::"G"(0.0) )' works fine.
>
> 'asm("instr %0"::"G"() );' doesn't work either.
>
> So '"G"(0.0)' is the only correct case.
>
> I set it to i8, since we just need convert it to zero. I suppose for
> avr-as it doesn't matter which kind of zero would be presented (0,
> 0x0 or 0.000). E.g. avr-gcc prints 0x0.
>
> -Stepan.
>
> P.S.: Just as playground code:
> // file: test.c
> // cmd: avr-gcc test.c -S -o -
> void f() {
> int a,b,c,d;
> asm("instr %0"::"G"(0.0) );
> }
>
>
>
>
>
> 2013/6/18 Borja Ferrer <bor...@gm...
> <mailto:bor...@gm...>
> <mailto:bor...@gm... <mailto:bor...@gm...>>__>
>
> Sure Stepan, go ahead. I can do any post commit cleanups
> afterwards.
>
>
> 2013/6/17 John Myers <ato...@gm...
> <mailto:ato...@gm...>
> <mailto:atomicdog.jwm@gmail.__com
> <mailto:ato...@gm...>>>
>
>
> You should have commit access.
>
>
> On Mon, Jun 17, 2013 at 1:35 PM, Stepan Dyatkovskiy
> <stp...@na... <mailto:stp...@na...>
> <mailto:stp...@na... <mailto:stp...@na...>>> wrote:
>
> Hi Borja,
> 2.1:
> You're right. Will return C_Register.
> About Q, I'd want to learn a bit more before it
> would be
> implemented. Perhaps there is nothing special, but
> I'd want
> to check.
> 2.2. Yes, we can return cw_constant. I had used ARM
> template
> :-) They just had set it as cw_other :-)
> 3. avr-llvm has appeared in "My Projects" in source
> forge
> menu. Does it mean I have permissions already? Can
> I do test
> commit (one more \n in README)?
> 4. I propose to commit everything (with fixes you
> proposed)
> to avoid growing snow ball patch ;-)
> --
> Truly yours,
> Stepan Dyatkovskiy
> 17.06.2013, 22:50, "Borja Ferrer"
> <bor...@gm... <mailto:bor...@gm...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>__>:
>
> Ok thanks for the fixes, more things:
>
> 2.1) AVRTargetLowering::__getConstraintType:
> Looking at
> other backends, I think the x, y, z, t
> constraints should
> return C_Register instead of C_RegisterClass
> since these
> are used for specific regs inside a regclass.
> Probably the
> same for the q one. What do you think?
>
> 2.2) Ok, so you've given the largest weight to
> the bigger
> regclasses d, r, l and then for the other reg
> constraints
> the smaller weight, I agree then.
> Now, for the constant constraints you should return
> CW_Constant instead, other backends first check
> that the
> imm val is in range and if it is then set it to
> that
> value, this is taken from the x86 one:
> case 'K':
> if (ConstantInt *C =
> dyn_cast<ConstantInt>(__CallOperandVal)) {
> if ((C->getSExtValue() >= -0x80) &&
> (C->getSExtValue() <= 0x7f))
> weight = CW_Constant;
> }
> break;
> Finally for Q we should return CW_Memory no?
>
> 2.3) In getRegForInlineAsmConstraint, if this
> inline asm
> stuff is run after type legalization you could
> turn that
> type checking at the top of the function into
> an assert()
> comment: Upper register r16..r32. <<-- typo
> registerS and r32
>
> John or Eric, please give Stepan commit
> permissions.
>
>
> 2013/6/17 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na...
> <mailto:stp...@na...>>>
>
>
> Hello Borja,
>
>
> ok here we go:
>
> 1) in AVRRegisterInfo.td: im ok with
> the lGPR8
> regclass since we dont
> have it yet and i guess it's needed for
> the l
> constraint, but rename it
> to GPR8lo. The hGPR8 regclass comment
> says lower
> registers, so typo
> there, but anyways can't you use the
> LD8 regclass?
> Rename simplehGPR8 to
> LD8lo, we'll need it in the future for
> some MUL
> instructions.
>
> Everything here were fixed as you mentioned.
>
>
>
> 2) in AVRISelLowering.cpp: for the t,
> x, y, z
> shouldn't we return
> C_Register? Probably for b aswell.
> 2.1) in getSingleConstraintMatchWeight
> can you
> clarify me what's the
> diff between CW_SpecificReg and
> CW_Register.
> Shouldn't the G constraint
> be a Constant? Same for the other
> constraints?
>
> All this stuff with weights is due to
> support of
> multiple constraints. For some operands you
> may set
> *the set* of constraints, e.g. 'mr': get
> either memory
> of register. In that case we're use
> weights. What
> should we select for 'bx' constraint for
> example? One
> of y,z or x? So, currently llvm gets
> register first
> from class with bigger weight. Since
> CW_SpecificReg <
> CW_Register it will select one of y,z.
>
> For more information see implementation of
>
> "TargetLowering::____getMultipleConstraintMatchWeig____ht"
> and "TargetLowering::____ParseConstraints".
>
>
> 'G' shouldn't be CW_Register, of course,
> that was my
> typo. I've fixed it, now it as all other
> constants
> just a CW_Default.
>
>
> 2.2) in getRegForInlineAsmConstraint
> fixup the
> regclasses per point (1).
> for w you could use the IWREGS
> regclass, the docs
> say they are regpairs,
> not 8 bit regs as you declared in the
> .td file.
>
> That was also fixed.
>
> -Stepan.
>
>
> The rest looks great.
>
>
> 2013/6/14 Borja Ferrer
> <bor...@gm... <mailto:bor...@gm...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>__>__>
>
>
> Going to review the patch now.
>
> No, there is no test for allocation
> order, I
> don't know a good way
> of testing that. If you want you
> can replace
> the register list by
> several sequences.
>
>
> 2013/6/14 Stepan Dyatkovskiy
> <stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>
> <mailto:stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na...
> <mailto:stp...@na...>>>>
>
>
> Hi Borja,
> All constraints are supported now.
> The new patch is attached.
>
> -- Added support for all documented
> constraints.
> -- Fixed tests as you mentioned.
>
> Relative to GPR8,
> Do we have some tests that check
> allocation order? If so, all of
> them were passed :-)
>
> Though I can use the explicit
> enumeration
> way you're currently
> using...
>
> -Stepan.
>
> Borja Ferrer wrote:
>
> Ok, there are some small
> style issues
> but i will fix them
> after you can
> commit (braces in
> AVRAsmPrinter::______PrintAsmOperand),
>
>
> afterwards you may
> check them for future
> reference.
>
> About the GPR8 replacement,
> I'm not
> sure now, but will it
> change the
> register allocation order
> using the
> "sequence" set
> instruction? This was
> changed some time ago so I dont
> remember what was the
> new...@na... <mailto:new...@na...>
>
> <mailto:stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na...
> <mailto:stp...@na...>>>>>>
>
>
>
> Hi all,
> I'll use this
> reference for
> implementation, right?
> http://savannah.nongnu.org/________download/avr-libc/avr-libc-________user-manual-1.8.0.pdf.__bz2
> <http://savannah.nongnu.org/______download/avr-libc/avr-libc-______user-manual-1.8.0.pdf.bz2>
>
> <http://savannah.nongnu.org/______download/avr-libc/avr-libc-______user-manual-1.8.0.pdf.bz2
> <http://savannah.nongnu.org/____download/avr-libc/avr-libc-____user-manual-1.8.0.pdf.bz2>>
>
>
>
> <http://savannah.nongnu.org/______download/avr-libc/avr-libc-______user-manual-1.8.0.pdf.bz2
> <http://savannah.nongnu.org/____download/avr-libc/avr-libc-____user-manual-1.8.0.pdf.bz2>
>
> <http://savannah.nongnu.org/____download/avr-libc/avr-libc-____user-manual-1.8.0.pdf.bz2
> <http://savannah.nongnu.org/__download/avr-libc/avr-libc-__user-manual-1.8.0.pdf.bz2>>>
>
>
>
>
>
> <http://savannah.nongnu.org/______download/avr-libc/avr-libc-______user-manual-1.8.0.pdf.bz2
> <http://savannah.nongnu.org/____download/avr-libc/avr-libc-____user-manual-1.8.0.pdf.bz2>
>
> <http://savannah.nongnu.org/____download/avr-libc/avr-libc-____user-manual-1.8.0.pdf.bz2
> <http://savannah.nongnu.org/__download/avr-libc/avr-libc-__user-manual-1.8.0.pdf.bz2>>
>
>
> <http://savannah.nongnu.org/____download/avr-libc/avr-libc-____user-manual-1.8.0.pdf.bz2
> <http://savannah.nongnu.org/__download/avr-libc/avr-libc-__user-manual-1.8.0.pdf.bz2>
>
> <http://savannah.nongnu.org/__download/avr-libc/avr-libc-__user-manual-1.8.0.pdf.bz2
> <http://savannah.nongnu.org/download/avr-libc/avr-libc-user-manual-1.8.0.pdf.bz2>>>>
>
> -Stepan.
>
> Stepan
> Dyatkovskiy
> wrote:
> > Ops.
> Forget to
> apply patch itself...
> >
> > -Stepan.
> >
> > Stepan
> Dyatkovskiy wrote:
> >> Hi
> all. That's a
> Thursday patch with
> inline asm.
> Currently
> the only
> >>
> constraint is
> supported: register ('r').
> >>
> >> -Stepan.
> >>
> >>
>
>
>
> ------------------------------________------------------------__--__--__--__------------------
>
>
>
> >>
> >> This
> SF.net
> email is sponsored by Windows:
> >>
> >> Build for
> Windows Store.
> >>
> >>
> http://p.sf.net/sfu/windows-________dev2dev
> <http://p.sf.net/sfu/windows-______dev2dev>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>>
>
>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>>>
>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>
> <http://p.sf.net/sfu/windows-__dev2dev
> <http://p.sf.net/sfu/windows-dev2dev>>>>
> >>
>
>
> _______________________________________________________
> >>
> avr-llvm-devel
> mailing list
> >>
> avr-llvm-devel@lists.__
> <mailto:avr-llvm-devel@lists.
> <mailto:avr-llvm-devel@lists.>____>sourcef____orge.net
> <http://sourcef____orge.net> <http://sourcef__orge.net/>
> <http://sourceforge.net
> <http://sourceforge.net/>>
>
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net/>
>
>
> <mailto:avr-llvm-devel@lists.
> <mailto:avr-llvm-devel@lists.>____sourceforge.net
> <http://sourceforge.net>
>
> <mailto:avr-llvm-devel@lists.__sourceforge.net
> <mailto:avr...@li...>>>>
>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>>.
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>>.__>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net/>
> <http://sourceforge.net
> <http://sourceforge.net/>>
>
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net/>
>
> <mailto:avr-llvm-devel@lists.
> <mailto:avr-llvm-devel@lists.>____sourceforge.net
> <http://sourceforge.net>
>
> <mailto:avr-llvm-devel@lists.__sourceforge.net
> <mailto:avr...@li...>>>>>
>
> >>
> https://lists.sourceforge.net/________lists/listinfo/avr-llvm-______devel
> <https://lists.sourceforge.net/______lists/listinfo/avr-llvm-____devel>
>
> <https://lists.sourceforge.__net/____lists/listinfo/avr-__llvm-__devel
> <https://lists.sourceforge.net/____lists/listinfo/avr-llvm-__devel>>
>
>
> <https://lists.sourceforge.____net/__lists/listinfo/avr-llvm-____devel
>
> <https://lists.sourceforge.__net/__lists/listinfo/avr-llvm-__devel
> <https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel>>>
>
> <https://lists.sourceforge.
>
> <https://lists.sourceforge./>______net/lists/listinfo/avr-__llvm-____devel
>
>
> <https://lists.sourceforge.____net/lists/listinfo/avr-llvm-____devel
>
> <https://lists.sourceforge.__net/lists/listinfo/avr-llvm-__devel
> <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel>>>>
> >>
> >
> >
> >
> >
>
>
>
>
> ------------------------------________------------------------__--__--__--__------------------
>
>
>
> > This
> SF.net email
> is sponsored by Windows:
> >
> > Build
> for Windows
> Store.
> >
> >
> http://p.sf.net/sfu/windows-________dev2dev
> <http://p.sf.net/sfu/windows-______dev2dev>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>>
>
>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>>>
>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>
> <http://p.sf.net/sfu/windows-__dev2dev
> <http://p.sf.net/sfu/windows-dev2dev>>>>
> >
> >
> >
> >
>
>
> _______________________________________________________
> >
> avr-llvm-devel
> mailing list
> >
> avr-llvm-devel@lists.__
> <mailto:avr-llvm-devel@lists.
> <mailto:avr-llvm-devel@lists.>____>sourcef____orge.net
> <http://sourcef____orge.net> <http://sourcef__orge.net/>
> <http://sourceforge.net
> <http://sourceforge.net/>>
>
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net/>
>
>
> <mailto:avr-llvm-devel@lists.
> <mailto:avr-llvm-devel@lists.>____sourceforge.net
> <http://sourceforge.net>
>
> <mailto:avr-llvm-devel@lists.__sourceforge.net
> <mailto:avr...@li...>>>>
>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>>.
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>>.__>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net/>
> <http://sourceforge.net
> <http://sourceforge.net/>>
>
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net/>
>
> <mailto:avr-llvm-devel@lists.
> <mailto:avr-llvm-devel@lists.>____sourceforge.net
> <http://sourceforge.net>
>
> <mailto:avr-llvm-devel@lists.__sourceforge.net
> <mailto:avr...@li...>>>>>
>
> >
> https://lists.sourceforge.net/________lists/listinfo/avr-llvm-______devel
> <https://lists.sourceforge.net/______lists/listinfo/avr-llvm-____devel>
>
> <https://lists.sourceforge.__net/____lists/listinfo/avr-__llvm-__devel
> <https://lists.sourceforge.net/____lists/listinfo/avr-llvm-__devel>>
>
>
> <https://lists.sourceforge.____net/__lists/listinfo/avr-llvm-____devel
>
> <https://lists.sourceforge.__net/__lists/listinfo/avr-llvm-__devel
> <https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel>>>
>
> <https://lists.sourceforge.
>
> <https://lists.sourceforge./>______net/lists/listinfo/avr-__llvm-____devel
>
>
> <https://lists.sourceforge.____net/lists/listinfo/avr-llvm-____devel
>
> <https://lists.sourceforge.__net/lists/listinfo/avr-llvm-__devel
> <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel>>>>
> >
>
>
>
>
>
>
> ------------------------------________------------------------__--__--__--__------------------
>
>
>
> This
> SF.net email is
> sponsored by Windows:
>
> Build for
> Windows Store.
> http://p.sf.net/sfu/windows-________dev2dev
> <http://p.sf.net/sfu/windows-______dev2dev>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>>
>
>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>>>
>
>
> <http://p.sf.net/sfu/windows-______dev2dev
> <http://p.sf.net/sfu/windows-____dev2dev>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>>
>
> <http://p.sf.net/sfu/windows-____dev2dev
> <http://p.sf.net/sfu/windows-__dev2dev>
> <http://p.sf.net/sfu/windows-__dev2dev
> <http://p.sf.net/sfu/windows-dev2dev>>>>
>
>
>
> _______________________________________________________
>
> avr-llvm-devel
> mailing list
> avr-llvm-devel@lists.__
>
> <mailto:%C2%A0avr-llvm-devel@__lists.__>sourcef____orge.net
> <http://sourcef____orge.net>
> <http://sourcef__orge.net/>
> <http://sourceforge.net
> <http://sourceforge.net/>>
>
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net/>
>
>
> <mailto:avr-llvm-devel@lists.
> <mailto:avr-llvm-devel@lists.>____sourceforge.net
> <http://sourceforge.net>
>
> <mailto:avr-llvm-devel@lists.__sourceforge.net
> <mailto:avr...@li...>>>>
>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>>.
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>>.__>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net/>
> <http://sourceforge.net
> <http://sourceforge.net/>>
>
>
> <mailto:avr-llvm-devel@lists <mailto:avr-llvm-devel@lists>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net/>
>
> <mailto:avr-llvm-devel@lists.
> <mailto:avr-llvm-devel@lists.>____sourceforge.net
> <http://sourceforge.net>
>
> <mailto:avr-llvm-devel@lists.__sourceforge.net
> <mailto:avr...@li...>>>>>
> https://lists.sourceforge.net/________lists/listinfo/avr-llvm-______devel
> <https://lists.sourceforge.net/______lists/listinfo/avr-llvm-____devel>
>
> <https://lists.sourceforge.__net/____lists/listinfo/avr-__llvm-__devel
> <https://lists.sourceforge.net/____lists/listinfo/avr-llvm-__devel>>
>
>
> <https://lists.sourceforge.____net/__lists/listinfo/avr-llvm-____devel
>
> <https://lists.sourceforge.__net/__lists/listinfo/avr-llvm-__devel
> <https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel>>>
>
> <https://lists.sourceforge.
>
> <https://lists.sourceforge./>______net/lists/listinfo/avr-__llvm-____devel
>
>
> <https://lists.sourceforge.____net/lists/listinfo/avr-llvm-____devel
>
> <https://lists.sourceforge.__net/lists/listinfo/avr-llvm-__devel
> <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel>>>>
>
>
>
>
>
>
>
>
>
>
>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-20 19:56:17
|
Hi Borja, > 2) there are some constraints to work with multi byte values (A0, B0, > C0, etc) that dont work at all, they produce wrong code. I guess this is > the next thing that should be implemented. OK. Will work at it. > One more thing, remember to commit the test cases when they're ready. Agh! Forgot to add it. So you mean to commit it now if they a ready? P.S.: Hope will present patch for memory constraint tomorrow. -Stepan. |
|
From: Borja F. <bor...@gm...> - 2013-06-21 00:40:14
|
Sure, commit it if you think it's ready, now it's very important to have test cases when new features are being added. Then when you implement the memory constraint, add a new test case. I've temporarily reverted the assert until we discover why it's failing, there's a FIXME to remind us. 2013/6/20 Stepan Dyatkovskiy <stp...@na...> > Hi Borja, > > > 2) there are some constraints to work with multi byte values (A0, B0, >> C0, etc) that dont work at all, they produce wrong code. I guess this is >> the next thing that should be implemented. >> > OK. Will work at it. > > > One more thing, remember to commit the test cases when they're ready. >> > Agh! Forgot to add it. So you mean to commit it now if they a ready? > > P.S.: Hope will present patch for memory constraint tomorrow. > > -Stepan. > |
|
From: Stepan D. <stp...@na...> - 2013-06-13 15:12:53
Attachments:
avr-inline-asm-2013-06-13-2.patch
|
Hi Borja, This is today patch. 1. Added and tested support for register constraints (a,b,d,e,q,r,t,w,x,y,z,l). 2. Refactored GPR8 registers class, added new registers classes: lGPR8, hGPR8, simplehGPR8 and specialUpperGPR8. 3. Fixed code-style. P.S.: In case you decided to give me commit access: 1. Do you have some AVR projects that are compilable with avr-llvm? I mean kind of llvm's test-suite replacement. 2. What ought to be tested before commit, except the "test/CodeGen/AVR" tests? 3. My SourceForge account name is: "kaomoneus". -Stepan. Borja Ferrer wrote: > The patch looks good, some comments about coding style. We use a > different standard compared to llvm's, most important things are: > 1) braces go into new lines. > 2) always place braces even if they're for a 1 line statement > > this: > + std::pair<unsigned, const TargetRegisterClass*> > + getRegForInlineAsmConstraint(const std::string &Constraint, > + EVT VT) const; > + > should be: > std::pair<unsigned, const TargetRegisterClass *> << space between > name and * > getRegForInlineAsmConstraint(const std::string &Constraint, EVT VT) const; > > this: > + ConstraintWeight getSingleConstraintMatchWeight( > + AsmOperandInfo &info, const char *constraint) const; > should be: > ConstraintWeight > getSingleConstraintMatchWeight(AsmOperandInfo &info, > const char *constraint) > const; > > > if there are any other small details i can fix them post commit. > > > > 2013/6/13 Borja Ferrer <bor...@gm... > <mailto:bor...@gm...>> > > Nice Stepan, I will review your patch later on. You should be given > commit access to this svn repo until we finally decide where to move > on all of the code. > > > 2013/6/13 Stepan Dyatkovskiy <stp...@na... > <mailto:stp...@na...>> > > Hi all, > I'll use this reference for implementation, right? > http://savannah.nongnu.org/download/avr-libc/avr-libc-user-manual-1.8.0.pdf.bz2 > > -Stepan. > > Stepan Dyatkovskiy wrote: > > Ops. Forget to apply patch itself... > > > > -Stepan. > > > > Stepan Dyatkovskiy wrote: > >> Hi all. That's a Thursday patch with inline asm. Currently > the only > >> constraint is supported: register ('r'). > >> > >> -Stepan. > >> > >> > ------------------------------------------------------------------------------ > >> > >> This SF.net email is sponsored by Windows: > >> > >> Build for Windows Store. > >> > >> http://p.sf.net/sfu/windows-dev2dev > >> _______________________________________________ > >> avr-llvm-devel mailing list > >> avr...@li... > <mailto:avr...@li...> > >> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > >> > > > > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > > > > > > > _______________________________________________ > > avr-llvm-devel mailing list > > avr...@li... > <mailto:avr...@li...> > > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > <mailto:avr...@li...> > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > > > |
|
From: Stepan D. <stp...@na...> - 2013-06-22 19:19:29
|
Hi Borja,
Borja Ferrer wrote:
> Resending the email to the list without any previous emails:
>
> Hello Stepan,
>
> 1) This should be fixed now with my last commit.
> 2) I dont really understand what you mean. Can you expand a bit more here?
Currently for line:
call void asm "some_instr $0", "=*Q"(i16* @b)
It does emit:
ldi r24, lo8(b)
ldi r25, hi8(b)
;APP
some_instr [r24]
While it shuold emit Y+q instead of r24 e.g.:
ldi YL , lo8(b)
ldi YH , hi8(b)
;APP
some_instr Y+1
-Stepan
|
|
From: Stepan D. <stp...@na...> - 2013-06-22 19:32:53
|
So I suppose, I need analyze Op in SelectInlineAsmMemoryOperand, then create virtual reg of PTRDISPREGS class and use it. -Stepan. Stepan Dyatkovskiy wrote: > Hi Borja, > > Borja Ferrer wrote: >> Resending the email to the list without any previous emails: >> >> Hello Stepan, >> >> 1) This should be fixed now with my last commit. >> 2) I dont really understand what you mean. Can you expand a bit more here? > > Currently for line: > > call void asm "some_instr $0", "=*Q"(i16* @b) > > It does emit: > > ldi r24, lo8(b) > ldi r25, hi8(b) > ;APP > some_instr [r24] > > While it shuold emit Y+q instead of r24 e.g.: > > ldi YL , lo8(b) > ldi YH , hi8(b) > ;APP > some_instr Y+1 > > -Stepan > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > |
|
From: Stepan D. <stp...@na...> - 2013-06-14 13:16:49
Attachments:
avr-inline-asm-2013-06-14.patch
|
Hi Borja, All constraints are supported now. The new patch is attached. -- Added support for all documented constraints. -- Fixed tests as you mentioned. Relative to GPR8, Do we have some tests that check allocation order? If so, all of them were passed :-) Though I can use the explicit enumeration way you're currently using... -Stepan. Borja Ferrer wrote: > Ok, there are some small style issues but i will fix them after you can > commit (braces in AVRAsmPrinter::PrintAsmOperand), afterwards you may > check them for future reference. > > About the GPR8 replacement, I'm not sure now, but will it change the > register allocation order using the "sequence" set instruction? This was > changed some time ago so I dont remember what was the new behaviour. > In the test cases please add a CHECK line for the function name, check > the other test cases in the folder to see what i mean. > You may need to add inline asm support in clang aswell, there are some > methods that need to be implemented there inside the AVR classes, > probably for error reporting stuff. > > 1) I dont know of any compatible projects, sorry. I've tested big C > programs like a floating point emulation library. > 2) for now only the tests there. > 3) John please give Stepan commit access to SVN. > > Heh Eric, that's ok, for inline asm there's no room for optimizations > but for other compiler features sure :) > > > > > 2013/6/13 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>> > > Hi Borja, > This is today patch. > 1. Added and tested support for register constraints > (a,b,d,e,q,r,t,w,x,y,z,l). > 2. Refactored GPR8 registers class, added new registers classes: > lGPR8, hGPR8, simplehGPR8 and specialUpperGPR8. > 3. Fixed code-style. > > P.S.: In case you decided to give me commit access: > 1. Do you have some AVR projects that are compilable with avr-llvm? > I mean kind of llvm's test-suite replacement. > 2. What ought to be tested before commit, except the > "test/CodeGen/AVR" tests? > 3. My SourceForge account name is: "kaomoneus". > > -Stepan. > > Borja Ferrer wrote: > > The patch looks good, some comments about coding style. We use a > different standard compared to llvm's, most important things are: > 1) braces go into new lines. > 2) always place braces even if they're for a 1 line statement > > this: > + std::pair<unsigned, const TargetRegisterClass*> > + getRegForInlineAsmConstraint(__const std::string > &Constraint, > + EVT VT) const; > + > should be: > std::pair<unsigned, const TargetRegisterClass *> << space > between > name and * > getRegForInlineAsmConstraint(__const std::string &Constraint, > EVT VT) const; > > this: > + ConstraintWeight getSingleConstraintMatchWeight__( > + AsmOperandInfo &info, const char *constraint) const; > should be: > ConstraintWeight > getSingleConstraintMatchWeight__(AsmOperandInfo &info, > const char > *constraint) > const; > > > if there are any other small details i can fix them post commit. > > > > 2013/6/13 Borja Ferrer <bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... <mailto:bor...@gm...>>__> > > > Nice Stepan, I will review your patch later on. You should > be given > commit access to this svn repo until we finally decide > where to move > on all of the code. > > > 2013/6/13 Stepan Dyatkovskiy <stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... <mailto:stp...@na...>>> > > > Hi all, > I'll use this reference for implementation, right? > http://savannah.nongnu.org/__download/avr-libc/avr-libc-__user-manual-1.8.0.pdf.bz2 > <http://savannah.nongnu.org/download/avr-libc/avr-libc-user-manual-1.8.0.pdf.bz2> > > -Stepan. > > Stepan Dyatkovskiy wrote: > > Ops. Forget to apply patch itself... > > > > -Stepan. > > > > Stepan Dyatkovskiy wrote: > >> Hi all. That's a Thursday patch with inline asm. > Currently > the only > >> constraint is supported: register ('r'). > >> > >> -Stepan. > >> > >> > > ------------------------------__------------------------------__------------------ > >> > >> This SF.net email is sponsored by Windows: > >> > >> Build for Windows Store. > >> > >> http://p.sf.net/sfu/windows-__dev2dev > <http://p.sf.net/sfu/windows-dev2dev> > >> _________________________________________________ > >> avr-llvm-devel mailing list > >> avr-llvm-devel@lists.__sourceforge.net > <mailto:avr...@li...> > <mailto:avr-llvm-devel@lists.__sourceforge.net > <mailto:avr...@li...>> > > >> > https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel > <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel> > >> > > > > > > > > > > ------------------------------__------------------------------__------------------ > > 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...> > <mailto:avr-llvm-devel@lists.__sourceforge.net > <mailto:avr...@li...>> > > > > https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel > <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel> > > > > > > ------------------------------__------------------------------__------------------ > 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...> > <mailto:avr-llvm-devel@lists.__sourceforge.net > <mailto:avr...@li...>> > https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel > <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel> > > > > > |
|
From: Borja F. <bor...@gm...> - 2013-06-23 00:46:35
|
Ok I understand it now. I will check what other backends do, but what you proposed seems reasonable. What happens in your example above when you use a real instruction like for example LDD? Does it still use GPR8 regs? To me it's weird that if you use a real instruction where operands are clearly defined in the td file the instruction selector uses an invalid regclass. 2013/6/22 Stepan Dyatkovskiy <stp...@na...> > So I suppose, I need analyze Op in SelectInlineAsmMemoryOperand, > then create virtual reg of PTRDISPREGS class and use it. > > -Stepan. > > Stepan Dyatkovskiy wrote: > >> Hi Borja, >> >> Borja Ferrer wrote: >> >>> Resending the email to the list without any previous emails: >>> >>> Hello Stepan, >>> >>> 1) This should be fixed now with my last commit. >>> 2) I dont really understand what you mean. Can you expand a bit more >>> here? >>> >> >> Currently for line: >> >> call void asm "some_instr $0", "=*Q"(i16* @b) >> >> It does emit: >> >> ldi r24, lo8(b) >> ldi r25, hi8(b) >> ;APP >> some_instr [r24] >> >> While it shuold emit Y+q instead of r24 e.g.: >> >> ldi YL , lo8(b) >> ldi YH , hi8(b) >> ;APP >> some_instr Y+1 >> >> -Stepan >> >> ------------------------------**------------------------------** >> ------------------ >> >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-**dev2dev<http://p.sf.net/sfu/windows-dev2dev> >> ______________________________**_________________ >> avr-llvm-devel mailing list >> avr-llvm-devel@lists.**sourceforge.net<avr...@li...> >> https://lists.sourceforge.net/**lists/listinfo/avr-llvm-devel<https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel> >> >> > |
|
From: Stepan D. <stp...@na...> - 2013-06-24 18:19:16
|
Hi Borja,
> What happens in your example above when you use a real instruction like
> for example LDD? Does it still use GPR8 regs? To me it's weird that if
> you use a real instruction where operands are clearly defined in the td
> file the instruction selector uses an invalid regclass.
There are two kinds of inline asm support in LLVM:
1. You just support all the constraints and pastes inline-asm contents
as-is. That's why its still allowed to use names like "some_instr".
2. You may expand inline-asm strings set, or in another words just parse
it onto set of instructions. In this case you have to implement
TargetLowering::ExpandInlineAsm method.
I'd want to start it on this week though...
But first we have to get avr-libc compilable (perhpas I read you
thoughts ;-) )
Relative to memory constrains. I implemented initial version it can
catch simplest cases (from test-case):
@a = internal global i16 0, align 4
@b = internal global i16 0, align 4
define void @mem() {
;CHECK: some_instr Z, Y
call void asm "some_instr $0, $1", "=*Q,=*Q"(i16* @a, i16* @b)
ret void
}
The patch is attached.
Its in my todo yet, to handle local variables. They could be emitted as
Y+q expression. Hope to present this support tomorrow. So if 'a' and 'b'
from example above would be local we could get "some_instr Y, Y+2"
-Stepan.
|
|
From: Stepan D. <stp...@na...> - 2013-06-24 18:19:53
Attachments:
avr-inline-asm-mem-2013-06-24.patch
|
The patch. Forgot to attach it.
-Stepan.
Stepan Dyatkovskiy wrote:
> Hi Borja,
>
> > What happens in your example above when you use a real instruction like
>> for example LDD? Does it still use GPR8 regs? To me it's weird that if
>> you use a real instruction where operands are clearly defined in the td
>> file the instruction selector uses an invalid regclass.
>
> There are two kinds of inline asm support in LLVM:
> 1. You just support all the constraints and pastes inline-asm contents
> as-is. That's why its still allowed to use names like "some_instr".
> 2. You may expand inline-asm strings set, or in another words just parse
> it onto set of instructions. In this case you have to implement
> TargetLowering::ExpandInlineAsm method.
> I'd want to start it on this week though...
>
> But first we have to get avr-libc compilable (perhpas I read you
> thoughts ;-) )
>
> Relative to memory constrains. I implemented initial version it can
> catch simplest cases (from test-case):
>
> @a = internal global i16 0, align 4
> @b = internal global i16 0, align 4
> define void @mem() {
> ;CHECK: some_instr Z, Y
> call void asm "some_instr $0, $1", "=*Q,=*Q"(i16* @a, i16* @b)
> ret void
> }
>
> The patch is attached.
>
> Its in my todo yet, to handle local variables. They could be emitted as
> Y+q expression. Hope to present this support tomorrow. So if 'a' and 'b'
> from example above would be local we could get "some_instr Y, Y+2"
>
> -Stepan.
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-24 23:43:18
|
Hello Stepan,
Heh well, the first step on being able to compile avr-libc is to add full
support for inline asm. Once that is finished we can then look at other
places that may still have problems.
The approach you're taking here looks sort of hacky :) but since i dont
have a deep understanding on inline asm i cant think of other alternatives.
I've been trying some code in gcc to see how this Q constraint works but i
wasnt able to compile it, what's wrong in here?
static char var;
char foo() {
char ret;
asm("ld %0, %1": "=r" (ret) : "Q" (var));
return ret;
}
I expected this to work.
Ok, having access to local vars using the Y+q addressing mode is important
since most of them will be in frame indexes.
I've noticed in your patch that you're checking in some places for the 'm'
constraint instead of Q, i know you copied it from the arm backend, but be
careful there in case things dont work as expected.
One last thing, I dont like not allowing Y and Z being inflated. This has
brought many problems in the past and blocks big size reduction
optimizations, disabling this for this inline asm feature is a very
expensive price that we can't pay. Hope this doesnt present any real issues
for you.
2013/6/24 Stepan Dyatkovskiy <stp...@na...>
> The patch. Forgot to attach it.
> -Stepan.
>
> Stepan Dyatkovskiy wrote:
>
>> Hi Borja,
>>
>> > What happens in your example above when you use a real instruction like
>>
>>> for example LDD? Does it still use GPR8 regs? To me it's weird that if
>>> you use a real instruction where operands are clearly defined in the td
>>> file the instruction selector uses an invalid regclass.
>>>
>>
>> There are two kinds of inline asm support in LLVM:
>> 1. You just support all the constraints and pastes inline-asm contents
>> as-is. That's why its still allowed to use names like "some_instr".
>> 2. You may expand inline-asm strings set, or in another words just parse
>> it onto set of instructions. In this case you have to implement
>> TargetLowering::**ExpandInlineAsm method.
>> I'd want to start it on this week though...
>>
>> But first we have to get avr-libc compilable (perhpas I read you
>> thoughts ;-) )
>>
>> Relative to memory constrains. I implemented initial version it can
>> catch simplest cases (from test-case):
>>
>> @a = internal global i16 0, align 4
>> @b = internal global i16 0, align 4
>> define void @mem() {
>> ;CHECK: some_instr Z, Y
>> call void asm "some_instr $0, $1", "=*Q,=*Q"(i16* @a, i16* @b)
>> ret void
>> }
>>
>> The patch is attached.
>>
>> Its in my todo yet, to handle local variables. They could be emitted as
>> Y+q expression. Hope to present this support tomorrow. So if 'a' and 'b'
>> from example above would be local we could get "some_instr Y, Y+2"
>>
>> -Stepan.
>>
>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-25 12:55:31
Attachments:
avr-inline-asm-mem-2013-06-25.patch
|
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-17 16:43:24
Attachments:
avr-inline-asm-2013-06-17.patch
|
Hello Borja, > ok here we go: > > 1) in AVRRegisterInfo.td: im ok with the lGPR8 regclass since we dont > have it yet and i guess it's needed for the l constraint, but rename it > to GPR8lo. The hGPR8 regclass comment says lower registers, so typo > there, but anyways can't you use the LD8 regclass? Rename simplehGPR8 to > LD8lo, we'll need it in the future for some MUL instructions. Everything here were fixed as you mentioned. > > 2) in AVRISelLowering.cpp: for the t, x, y, z shouldn't we return > C_Register? Probably for b aswell. > 2.1) in getSingleConstraintMatchWeight can you clarify me what's the > diff between CW_SpecificReg and CW_Register. Shouldn't the G constraint > be a Constant? Same for the other constraints? All this stuff with weights is due to support of multiple constraints. For some operands you may set *the set* of constraints, e.g. 'mr': get either memory of register. In that case we're use weights. What should we select for 'bx' constraint for example? One of y,z or x? So, currently llvm gets register first from class with bigger weight. Since CW_SpecificReg < CW_Register it will select one of y,z. For more information see implementation of "TargetLowering::getMultipleConstraintMatchWeight" and "TargetLowering::ParseConstraints". 'G' shouldn't be CW_Register, of course, that was my typo. I've fixed it, now it as all other constants just a CW_Default. > 2.2) in getRegForInlineAsmConstraint fixup the regclasses per point (1). > for w you could use the IWREGS regclass, the docs say they are regpairs, > not 8 bit regs as you declared in the .td file. That was also fixed. -Stepan. > > The rest looks great. > > > 2013/6/14 Borja Ferrer <bor...@gm... > <mailto:bor...@gm...>> > > Going to review the patch now. > > No, there is no test for allocation order, I don't know a good way > of testing that. If you want you can replace the register list by > several sequences. > > > 2013/6/14 Stepan Dyatkovskiy <stp...@na... > <mailto:stp...@na...>> > > Hi Borja, > All constraints are supported now. > The new patch is attached. > > -- Added support for all documented constraints. > -- Fixed tests as you mentioned. > > Relative to GPR8, > Do we have some tests that check allocation order? If so, all of > them were passed :-) > > Though I can use the explicit enumeration way you're currently > using... > > -Stepan. > > Borja Ferrer wrote: > > Ok, there are some small style issues but i will fix them > after you can > commit (braces in AVRAsmPrinter::__PrintAsmOperand), > afterwards you may > check them for future reference. > > About the GPR8 replacement, I'm not sure now, but will it > change the > register allocation order using the "sequence" set > instruction? This was > changed some time ago so I dont remember what was the new > behaviour. > In the test cases please add a CHECK line for the function > name, check > the other test cases in the folder to see what i mean. > You may need to add inline asm support in clang aswell, > there are some > methods that need to be implemented there inside the AVR > classes, > probably for error reporting stuff. > > 1) I dont know of any compatible projects, sorry. I've > tested big C > programs like a floating point emulation library. > 2) for now only the tests there. > 3) John please give Stepan commit access to SVN. > > Heh Eric, that's ok, for inline asm there's no room for > optimizations > but for other compiler features sure :) > > > > > 2013/6/13 Stepan Dyatkovskiy <stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>>> > > > Hi Borja, > This is today patch. > 1. Added and tested support for register constraints > (a,b,d,e,q,r,t,w,x,y,z,l). > 2. Refactored GPR8 registers class, added new registers > classes: > lGPR8, hGPR8, simplehGPR8 and specialUpperGPR8. > 3. Fixed code-style. > > P.S.: In case you decided to give me commit access: > 1. Do you have some AVR projects that are compilable > with avr-llvm? > I mean kind of llvm's test-suite replacement. > 2. What ought to be tested before commit, except the > "test/CodeGen/AVR" tests? > 3. My SourceForge account name is: "kaomoneus". > > -Stepan. > > Borja Ferrer wrote: > > The patch looks good, some comments about coding > style. We use a > different standard compared to llvm's, most > important things are: > 1) braces go into new lines. > 2) always place braces even if they're for a 1 line > statement > > this: > + std::pair<unsigned, const TargetRegisterClass*> > + getRegForInlineAsmConstraint(____const > std::string > > &Constraint, > + EVT VT) const; > + > should be: > std::pair<unsigned, const TargetRegisterClass *> > << space > between > name and * > getRegForInlineAsmConstraint(____const std::string > &Constraint, > EVT VT) const; > > this: > + ConstraintWeight getSingleConstraintMatchWeight____( > > + AsmOperandInfo &info, const char *constraint) > const; > should be: > ConstraintWeight > getSingleConstraintMatchWeight____(AsmOperandInfo > &info, > > > const char > *constraint) > const; > > > if there are any other small details i can fix them > post commit. > > > > 2013/6/13 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...>>__>__> > > > > Nice Stepan, I will review your patch later > on. You should > be given > commit access to this svn repo until we > finally decide > where to move > on all of the code. > > > 2013/6/13 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 all, > I'll use this reference for > implementation, right? > http://savannah.nongnu.org/____download/avr-libc/avr-libc-____user-manual-1.8.0.pdf.bz2 > <http://savannah.nongnu.org/__download/avr-libc/avr-libc-__user-manual-1.8.0.pdf.bz2> > > > <http://savannah.nongnu.org/__download/avr-libc/avr-libc-__user-manual-1.8.0.pdf.bz2 > <http://savannah.nongnu.org/download/avr-libc/avr-libc-user-manual-1.8.0.pdf.bz2>> > > -Stepan. > > Stepan Dyatkovskiy wrote: > > Ops. Forget to apply patch itself... > > > > -Stepan. > > > > Stepan Dyatkovskiy wrote: > >> Hi all. That's a Thursday patch with > inline asm. > Currently > the only > >> constraint is supported: register ('r'). > >> > >> -Stepan. > >> > >> > > > ------------------------------____----------------------------__--__------------------ > > >> > >> This SF.net email is sponsored by Windows: > >> > >> Build for Windows Store. > >> > >> > http://p.sf.net/sfu/windows-____dev2dev > <http://p.sf.net/sfu/windows-__dev2dev> > <http://p.sf.net/sfu/windows-__dev2dev > <http://p.sf.net/sfu/windows-dev2dev>> > >> > ___________________________________________________ > >> avr-llvm-devel mailing list > >> > avr-llvm-devel@lists.__sourcef__orge.net > <http://sourceforge.net> > <mailto:avr-llvm-devel@lists.__sourceforge.net > <mailto:avr...@li...>> > <mailto:avr-llvm-devel@lists. > <mailto:avr-llvm-devel@lists.>____sourceforge.net > <http://sourceforge.net> > <mailto:avr-llvm-devel@lists.__sourceforge.net > <mailto:avr...@li...>>> > > >> > https://lists.sourceforge.net/____lists/listinfo/avr-llvm-__devel > <https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel> > > <https://lists.sourceforge.__net/lists/listinfo/avr-llvm-__devel > <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel>> > >> > > > > > > > > > > > ------------------------------____----------------------------__--__------------------ > > > 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 > <mailto:avr...@li...>> > <mailto:avr-llvm-devel@lists. > <mailto:avr-llvm-devel@lists.>____sourceforge.net > <http://sourceforge.net> > <mailto:avr-llvm-devel@lists.__sourceforge.net > <mailto:avr...@li...>>> > > > > https://lists.sourceforge.net/____lists/listinfo/avr-llvm-__devel > <https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel> > > <https://lists.sourceforge.__net/lists/listinfo/avr-llvm-__devel > <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel>> > > > > > > > ------------------------------____----------------------------__--__------------------ > > 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 > <mailto:avr...@li...>> > <mailto:avr-llvm-devel@lists. > <mailto:avr-llvm-devel@lists.>____sourceforge.net > <http://sourceforge.net> > <mailto:avr-llvm-devel@lists.__sourceforge.net > <mailto:avr...@li...>>> > https://lists.sourceforge.net/____lists/listinfo/avr-llvm-__devel > <https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel> > > <https://lists.sourceforge.__net/lists/listinfo/avr-llvm-__devel > <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel>> > > > > > > > > |
|
From: Stepan D. <stp...@na...> - 2013-06-25 14:31:00
|
Hi Borja,
> Ahh, I didn't know avr-gcc was buggy on this feature, that's probably
> the reason for why the code i pasted in my previous email didn't work.
...
> What's wrong with clang? I fixed clang inline asm support back on
> friday, so is there anything else that is broken?
It should emit '*Q' instead of 'Q'. That's why code from prev. email
didn't work, just compare -emit-llvm -S output of avr-clang with other
backends,
> About the getPointerRegClass function, what is it used for? Also, please
> move the implementation to the cpp file instead of leaving it in the .h.
Currently, it is used in registers coelescing pass. While being
registers inflating, llvm lookups all register uses. If it found that
register is used by inline-asm as memory operand, it requests the
pointer class with this method (I think the largest one). But may be in
future this method will be used in more cases.
avr-gcc has buggy implementation of memory constraint, that's why
avr-libs doesn't use it at all. We have a chance to be first here :-)
-Stepan
>
>
>
> 2013/6/25 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>>
>
> Hi Borja.
> This is new patch. Seems I've moved memory constraint implementation
> to the same level like all other constraints. Note avr-gcc has buggy
> implementation of memory constraint, that's why *avr-libc doesn't
> use it*.
>
> I removed restriction for Y,Z in getLargestLegalSuperClass, so these
> registers could be inflated now. But there was unimplemented
> getPointerRegClass method in AVRRegistersInfo. So currently I have
> restricted it to Y and Z. Though suppose we can extend it in future
> to XYZ set.
> Look changes in inline-asm.ll to see what exactly is supported now.
>
> About clang.
> May be we ask John Myers to fix clang support for inline asm?
>
> -Stepan.
>
>
> Stepan Dyatkovskiy wrote:
>
> The patch. Forgot to attach it.
> -Stepan.
> Stepan Dyatkovskiy wrote:
>
> Hi Borja,
>
> > What happens in your example above when you use a real
> instruction
> like
>
> for example LDD? Does it still use GPR8 regs? To me it's
> weird that if
> you use a real instruction where operands are clearly
> defined in the td
> file the instruction selector uses an invalid regclass.
>
>
> There are two kinds of inline asm support in LLVM:
> 1. You just support all the constraints and pastes
> inline-asm contents
> as-is. That's why its still allowed to use names like
> "some_instr".
> 2. You may expand inline-asm strings set, or in another
> words just parse
> it onto set of instructions. In this case you have to implement
> TargetLowering::__ExpandInlineAsm method.
> I'd want to start it on this week though...
>
> But first we have to get avr-libc compilable (perhpas I read you
> thoughts ;-) )
>
> Relative to memory constrains. I implemented initial version
> it can
> catch simplest cases (from test-case):
>
> @a = internal global i16 0, align 4
> @b = internal global i16 0, align 4
> define void @mem() {
> ;CHECK: some_instr Z, Y
> call void asm "some_instr $0, $1", "=*Q,=*Q"(i16* @a,
> i16* @b)
> ret void
> }
>
> The patch is attached.
>
> Its in my todo yet, to handle local variables. They could be
> emitted as
> Y+q expression. Hope to present this support tomorrow. So if
> 'a' and 'b'
> from example above would be local we could get "some_instr
> Y, Y+2"
>
> -Stepan.
>
>
>
>
>
|
|
From: Stepan D. <stp...@na...> - 2013-06-27 11:43:52
|
Hm... Didn't you get my previous mail? If not, I think, I have to change
my mail box.
-Stepan
-------- Original Message --------
Subject: Re: [avr-llvm-devel] Inline assembly. Mostly just a stub.
Date: Tue, 25 Jun 2013 18:30:46 +0400
From: Stepan Dyatkovskiy <stp...@na...>
To: Borja Ferrer <bor...@gm...>
CC: avr-llvm <avr...@li...>, John Myers
<ato...@gm...>
Hi Borja,
> Ahh, I didn't know avr-gcc was buggy on this feature, that's probably
> the reason for why the code i pasted in my previous email didn't work.
...
> What's wrong with clang? I fixed clang inline asm support back on
> friday, so is there anything else that is broken?
It should emit '*Q' instead of 'Q'. That's why code from prev. email
didn't work, just compare -emit-llvm -S output of avr-clang with other
backends,
> About the getPointerRegClass function, what is it used for? Also, please
> move the implementation to the cpp file instead of leaving it in the .h.
Currently, it is used in registers coelescing pass. While being
registers inflating, llvm lookups all register uses. If it found that
register is used by inline-asm as memory operand, it requests the
pointer class with this method (I think the largest one). But may be in
future this method will be used in more cases.
avr-gcc has buggy implementation of memory constraint, that's why
avr-libs doesn't use it at all. We have a chance to be first here :-)
-Stepan
>
>
>
> 2013/6/25 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>>
>
> Hi Borja.
> This is new patch. Seems I've moved memory constraint implementation
> to the same level like all other constraints. Note avr-gcc has buggy
> implementation of memory constraint, that's why *avr-libc doesn't
> use it*.
>
> I removed restriction for Y,Z in getLargestLegalSuperClass, so these
> registers could be inflated now. But there was unimplemented
> getPointerRegClass method in AVRRegistersInfo. So currently I have
> restricted it to Y and Z. Though suppose we can extend it in future
> to XYZ set.
> Look changes in inline-asm.ll to see what exactly is supported now.
>
> About clang.
> May be we ask John Myers to fix clang support for inline asm?
>
> -Stepan.
>
>
> Stepan Dyatkovskiy wrote:
>
> The patch. Forgot to attach it.
> -Stepan.
> Stepan Dyatkovskiy wrote:
>
> Hi Borja,
>
> > What happens in your example above when you use a real
> instruction
> like
>
> for example LDD? Does it still use GPR8 regs? To me it's
> weird that if
> you use a real instruction where operands are clearly
> defined in the td
> file the instruction selector uses an invalid regclass.
>
>
> There are two kinds of inline asm support in LLVM:
> 1. You just support all the constraints and pastes
> inline-asm contents
> as-is. That's why its still allowed to use names like
> "some_instr".
> 2. You may expand inline-asm strings set, or in another
> words just parse
> it onto set of instructions. In this case you have to implement
> TargetLowering::__ExpandInlineAsm method.
> I'd want to start it on this week though...
>
> But first we have to get avr-libc compilable (perhpas I read you
> thoughts ;-) )
>
> Relative to memory constrains. I implemented initial version
> it can
> catch simplest cases (from test-case):
>
> @a = internal global i16 0, align 4
> @b = internal global i16 0, align 4
> define void @mem() {
> ;CHECK: some_instr Z, Y
> call void asm "some_instr $0, $1", "=*Q,=*Q"(i16* @a,
> i16* @b)
> ret void
> }
>
> The patch is attached.
>
> Its in my todo yet, to handle local variables. They could be
> emitted as
> Y+q expression. Hope to present this support tomorrow. So if
> 'a' and 'b'
> from example above would be local we could get "some_instr
> Y, Y+2"
>
> -Stepan.
>
>
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-06-27 11:47:14
|
No, your last email only says : "So, can I commit that memory constraint patch?" 2013/6/27 Stepan Dyatkovskiy <stp...@na...> > Hm... Didn't you get my previous mail? If not, I think, I have to change > my mail box. > > -Stepan > > > -------- Original Message -------- > Subject: Re: [avr-llvm-devel] Inline assembly. Mostly just a stub. > Date: Tue, 25 Jun 2013 18:30:46 +0400 > From: Stepan Dyatkovskiy <stp...@na...> > To: Borja Ferrer <bor...@gm...> > CC: avr-llvm <avr-llvm-devel@lists.**sourceforge.net<avr...@li...>>, > John Myers <ato...@gm...> > > Hi Borja, > > Ahh, I didn't know avr-gcc was buggy on this feature, that's probably >> the reason for why the code i pasted in my previous email didn't work. >> > ... > >> What's wrong with clang? I fixed clang inline asm support back on >> friday, so is there anything else that is broken? >> > It should emit '*Q' instead of 'Q'. That's why code from prev. email > didn't work, just compare -emit-llvm -S output of avr-clang with other > backends, > > About the getPointerRegClass function, what is it used for? Also, please >> move the implementation to the cpp file instead of leaving it in the .h. >> > Currently, it is used in registers coelescing pass. While being > registers inflating, llvm lookups all register uses. If it found that > register is used by inline-asm as memory operand, it requests the > pointer class with this method (I think the largest one). But may be in > future this method will be used in more cases. > > avr-gcc has buggy implementation of memory constraint, that's why > avr-libs doesn't use it at all. We have a chance to be first here :-) > > -Stepan > > >> >> >> 2013/6/25 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na... >> >> >> >> Hi Borja. >> This is new patch. Seems I've moved memory constraint implementation >> to the same level like all other constraints. Note avr-gcc has buggy >> implementation of memory constraint, that's why *avr-libc doesn't >> use it*. >> >> I removed restriction for Y,Z in getLargestLegalSuperClass, so these >> registers could be inflated now. But there was unimplemented >> getPointerRegClass method in AVRRegistersInfo. So currently I have >> restricted it to Y and Z. Though suppose we can extend it in future >> to XYZ set. >> Look changes in inline-asm.ll to see what exactly is supported now. >> >> About clang. >> May be we ask John Myers to fix clang support for inline asm? >> >> -Stepan. >> >> >> Stepan Dyatkovskiy wrote: >> >> The patch. Forgot to attach it. >> -Stepan. >> Stepan Dyatkovskiy wrote: >> >> Hi Borja, >> >> > What happens in your example above when you use a real >> instruction >> like >> >> for example LDD? Does it still use GPR8 regs? To me it's >> weird that if >> you use a real instruction where operands are clearly >> defined in the td >> file the instruction selector uses an invalid regclass. >> >> >> There are two kinds of inline asm support in LLVM: >> 1. You just support all the constraints and pastes >> inline-asm contents >> as-is. That's why its still allowed to use names like >> "some_instr". >> 2. You may expand inline-asm strings set, or in another >> words just parse >> it onto set of instructions. In this case you have to >> implement >> TargetLowering::__**ExpandInlineAsm method. >> I'd want to start it on this week though... >> >> But first we have to get avr-libc compilable (perhpas I read >> you >> thoughts ;-) ) >> >> Relative to memory constrains. I implemented initial version >> it can >> catch simplest cases (from test-case): >> >> @a = internal global i16 0, align 4 >> @b = internal global i16 0, align 4 >> define void @mem() { >> ;CHECK: some_instr Z, Y >> call void asm "some_instr $0, $1", "=*Q,=*Q"(i16* @a, >> i16* @b) >> ret void >> } >> >> The patch is attached. >> >> Its in my todo yet, to handle local variables. They could be >> emitted as >> Y+q expression. Hope to present this support tomorrow. So if >> 'a' and 'b' >> from example above would be local we could get "some_instr >> Y, Y+2" >> >> -Stepan. >> >> >> >> >> >> > |
|
From: Borja F. <bor...@gm...> - 2013-06-27 14:35:19
|
Stepan, reply in this thread to my 2 questions again if the email got lost. 2013/6/27 Borja Ferrer <bor...@gm...> > No, your last email only says : "So, can I commit that memory constraint > patch?" > > > 2013/6/27 Stepan Dyatkovskiy <stp...@na...> > >> Hm... Didn't you get my previous mail? If not, I think, I have to change >> my mail box. >> >> -Stepan >> >> >> -------- Original Message -------- >> Subject: Re: [avr-llvm-devel] Inline assembly. Mostly just a stub. >> Date: Tue, 25 Jun 2013 18:30:46 +0400 >> From: Stepan Dyatkovskiy <stp...@na...> >> To: Borja Ferrer <bor...@gm...> >> CC: avr-llvm <avr-llvm-devel@lists.**sourceforge.net<avr...@li...>>, >> John Myers <ato...@gm...> >> >> Hi Borja, >> >> Ahh, I didn't know avr-gcc was buggy on this feature, that's probably >>> the reason for why the code i pasted in my previous email didn't work. >>> >> ... >> >>> What's wrong with clang? I fixed clang inline asm support back on >>> friday, so is there anything else that is broken? >>> >> It should emit '*Q' instead of 'Q'. That's why code from prev. email >> didn't work, just compare -emit-llvm -S output of avr-clang with other >> backends, >> >> About the getPointerRegClass function, what is it used for? Also, please >>> move the implementation to the cpp file instead of leaving it in the .h. >>> >> Currently, it is used in registers coelescing pass. While being >> registers inflating, llvm lookups all register uses. If it found that >> register is used by inline-asm as memory operand, it requests the >> pointer class with this method (I think the largest one). But may be in >> future this method will be used in more cases. >> >> avr-gcc has buggy implementation of memory constraint, that's why >> avr-libs doesn't use it at all. We have a chance to be first here :-) >> >> -Stepan >> >> >>> >>> >>> 2013/6/25 Stepan Dyatkovskiy <stp...@na... <mailto: >>> stp...@na...>> >>> >>> Hi Borja. >>> This is new patch. Seems I've moved memory constraint implementation >>> to the same level like all other constraints. Note avr-gcc has buggy >>> implementation of memory constraint, that's why *avr-libc doesn't >>> use it*. >>> >>> I removed restriction for Y,Z in getLargestLegalSuperClass, so these >>> registers could be inflated now. But there was unimplemented >>> getPointerRegClass method in AVRRegistersInfo. So currently I have >>> restricted it to Y and Z. Though suppose we can extend it in future >>> to XYZ set. >>> Look changes in inline-asm.ll to see what exactly is supported now. >>> >>> About clang. >>> May be we ask John Myers to fix clang support for inline asm? >>> >>> -Stepan. >>> >>> >>> Stepan Dyatkovskiy wrote: >>> >>> The patch. Forgot to attach it. >>> -Stepan. >>> Stepan Dyatkovskiy wrote: >>> >>> Hi Borja, >>> >>> > What happens in your example above when you use a real >>> instruction >>> like >>> >>> for example LDD? Does it still use GPR8 regs? To me it's >>> weird that if >>> you use a real instruction where operands are clearly >>> defined in the td >>> file the instruction selector uses an invalid regclass. >>> >>> >>> There are two kinds of inline asm support in LLVM: >>> 1. You just support all the constraints and pastes >>> inline-asm contents >>> as-is. That's why its still allowed to use names like >>> "some_instr". >>> 2. You may expand inline-asm strings set, or in another >>> words just parse >>> it onto set of instructions. In this case you have to >>> implement >>> TargetLowering::__**ExpandInlineAsm method. >>> I'd want to start it on this week though... >>> >>> But first we have to get avr-libc compilable (perhpas I read >>> you >>> thoughts ;-) ) >>> >>> Relative to memory constrains. I implemented initial version >>> it can >>> catch simplest cases (from test-case): >>> >>> @a = internal global i16 0, align 4 >>> @b = internal global i16 0, align 4 >>> define void @mem() { >>> ;CHECK: some_instr Z, Y >>> call void asm "some_instr $0, $1", "=*Q,=*Q"(i16* @a, >>> i16* @b) >>> ret void >>> } >>> >>> The patch is attached. >>> >>> Its in my todo yet, to handle local variables. They could be >>> emitted as >>> Y+q expression. Hope to present this support tomorrow. So if >>> 'a' and 'b' >>> from example above would be local we could get "some_instr >>> Y, Y+2" >>> >>> -Stepan. >>> >>> >>> >>> >>> >>> >> > |
|
From: Borja F. <bor...@gm...> - 2013-06-27 17:36:59
|
Yes, and then I replied the following:
For this C code:
char delay_count;
char aaa;
uint8_t delay(unsigned char p)
{
uint8_t cnt;
asm volatile (
"inst %0, %1" "\n\t"
: "=Q" (delay_count)
: "Q" (aaa));
return cnt;
}
Clang produces:
define i8 @delay(i8 %p) #0 {
entry:
tail call void asm sideeffect "inst $0, $1\0A\09", "=*Q,*Q"(i8*
@delay_count, i8* @aaa) #2, !srcloc !4
ret i8 undef
}
notice the *Q constraints, so is there anything wrong in there?
Is there anything else that needs to be covered for the memory constraint?
2013/6/27 Stepan Dyatkovskiy <stp...@na...>
> Hi Borja,
>
> > Stepan, reply in this thread to my 2 questions again if the email got
> lost.
>
> My prev. reply:
>
>
> > Ahh, I didn't know avr-gcc was buggy on this feature, that's probably
> > the reason for why the code i pasted in my previous email didn't work.
> ...
> > What's wrong with clang? I fixed clang inline asm support back on
> > friday, so is there anything else that is broken?
> It should emit '*Q' instead of 'Q'. That's why code from prev. email
> didn't work, just compare -emit-llvm -S output of avr-clang with other
> backends,
>
> > About the getPointerRegClass function, what is it used for? Also, please
> > move the implementation to the cpp file instead of leaving it in the .h.
> Currently, it is used in registers coelescing pass. While being registers
> inflating, llvm lookups all register uses. If it found that register is
> used by inline-asm as memory operand, it requests the pointer class with
> this method (I think the largest one). But may be in future this method
> will be used in more cases.
>
> avr-gcc has buggy implementation of memory constraint, that's why avr-libs
> doesn't use it at all. We have a chance to be first here
>
> -Stepan
>
> Borja Ferrer wrote:
>
>> Stepan, reply in this thread to my 2 questions again if the email got
>> lost.
>>
>>
>> 2013/6/27 Borja Ferrer <bor...@gm...
>> <mailto:bor...@gm...>**>
>>
>>
>> No, your last email only says : "So, can I commit that memory
>> constraint patch?"
>>
>>
>> 2013/6/27 Stepan Dyatkovskiy <stp...@na...
>> <mailto:stp...@na...>>
>>
>>
>> Hm... Didn't you get my previous mail? If not, I think, I have
>> to change my mail box.
>>
>> -Stepan
>>
>>
>> -------- Original Message --------
>> Subject: Re: [avr-llvm-devel] Inline assembly. Mostly just a stub.
>> Date: Tue, 25 Jun 2013 18:30:46 +0400
>> From: Stepan Dyatkovskiy <stp...@na...
>> <mailto:stp...@na...>>
>> To: Borja Ferrer <bor...@gm...
>> <mailto:bor...@gm...>**>
>> CC: avr-llvm <avr-llvm-devel@lists.__source**forge.net<http://sourceforge.net>
>> <mailto:avr-llvm-devel@lists.**sourceforge.net<avr...@li...>>>,
>> John Myers
>> <ato...@gm... <mailto:atomicdog.jwm@gmail.**com<ato...@gm...>
>> >>
>>
>> Hi Borja,
>>
>> Ahh, I didn't know avr-gcc was buggy on this feature, that's
>> probably
>> the reason for why the code i pasted in my previous email
>> didn't work.
>>
>> ...
>>
>> What's wrong with clang? I fixed clang inline asm support
>> back on
>> friday, so is there anything else that is broken?
>>
>> It should emit '*Q' instead of 'Q'. That's why code from prev.
>> email
>> didn't work, just compare -emit-llvm -S output of avr-clang with
>> other
>> backends,
>>
>> About the getPointerRegClass function, what is it used for?
>> Also, please
>> move the implementation to the cpp file instead of leaving
>> it in the .h.
>>
>> Currently, it is used in registers coelescing pass. While being
>> registers inflating, llvm lookups all register uses. If it found
>> that
>> register is used by inline-asm as memory operand, it requests the
>> pointer class with this method (I think the largest one). But
>> may be in
>> future this method will be used in more cases.
>>
>> avr-gcc has buggy implementation of memory constraint, that's why
>> avr-libs doesn't use it at all. We have a chance to be first
>> here :-)
>>
>> -Stepan
>>
>>
>>
>>
>> 2013/6/25 Stepan Dyatkovskiy <stp...@na...
>> <mailto:stp...@na...> <mailto:stp...@na...
>>
>> <mailto:stp...@na...>>>
>>
>> Hi Borja.
>> This is new patch. Seems I've moved memory constraint
>> implementation
>> to the same level like all other constraints. Note
>> avr-gcc has buggy
>> implementation of memory constraint, that's why
>> *avr-libc doesn't
>> use it*.
>>
>> I removed restriction for Y,Z in
>> getLargestLegalSuperClass, so these
>> registers could be inflated now. But there was
>> unimplemented
>> getPointerRegClass method in AVRRegistersInfo. So
>> currently I have
>> restricted it to Y and Z. Though suppose we can extend
>> it in future
>> to XYZ set.
>> Look changes in inline-asm.ll to see what exactly is
>> supported now.
>>
>> About clang.
>> May be we ask John Myers to fix clang support for
>> inline asm?
>>
>> -Stepan.
>>
>>
>> Stepan Dyatkovskiy wrote:
>>
>> The patch. Forgot to attach it.
>> -Stepan.
>> Stepan Dyatkovskiy wrote:
>>
>> Hi Borja,
>>
>> > What happens in your example above when you
>> use a real
>> instruction
>> like
>>
>> for example LDD? Does it still use GPR8
>> regs? To me it's
>> weird that if
>> you use a real instruction where operands
>> are clearly
>> defined in the td
>> file the instruction selector uses an
>> invalid regclass.
>>
>>
>> There are two kinds of inline asm support in
>> LLVM:
>> 1. You just support all the constraints and
>> pastes
>> inline-asm contents
>> as-is. That's why its still allowed to use
>> names like
>> "some_instr".
>> 2. You may expand inline-asm strings set, or in
>> another
>> words just parse
>> it onto set of instructions. In this case you
>> have to implement
>> TargetLowering::____**ExpandInlineAsm method.
>>
>> I'd want to start it on this week though...
>>
>> But first we have to get avr-libc compilable
>> (perhpas I read you
>> thoughts ;-) )
>>
>> Relative to memory constrains. I implemented
>> initial version
>> it can
>> catch simplest cases (from test-case):
>>
>> @a = internal global i16 0, align 4
>> @b = internal global i16 0, align 4
>> define void @mem() {
>> ;CHECK: some_instr Z, Y
>> call void asm "some_instr $0, $1",
>> "=*Q,=*Q"(i16* @a,
>> i16* @b)
>> ret void
>> }
>>
>> The patch is attached.
>>
>> Its in my todo yet, to handle local variables.
>> They could be
>> emitted as
>> Y+q expression. Hope to present this support
>> tomorrow. So if
>> 'a' and 'b'
>> from example above would be local we could get
>> "some_instr
>> Y, Y+2"
>>
>> -Stepan.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
|
|
From: 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: 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 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: 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: 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: 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 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>
>>>>>
>>>>>
>>>>
>>>
>>
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X