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