llvm dev - Apr 2015 - [LLVMdev] [PATCH] fix outs/ins of MOV16mr instruction (X86)

On Wed, Mar 25, 2015 at 10:28 AM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> >> Why?  i16mem here stands for the pointer, not the actual memory. 
A
> >> store doesn't define a pointer, so why would it be in
"outs"?
> >
> > Then why does this "i16mem:$dst" belongs to "ins"?
Is that wrong,
> correct?
>
> Think about a typical instruction:
>
>     movw %ax, 1234(%rax, 4, %rbx)
>
> The components making up the "i16mem" operand are
"1234", %rax, 4 and
> %rbx (+ a hidden segment register). None of those are defined/written
> by the instruction (but they are read). So they need to be ins.
>
> What's written is some nebulous memory location specified by those
> operands. This isn't modelled by LLVM's basic instructions at all
> (except possibly via mayLoad and mayStore).
>
Got it, thanks!

A question: I still dont really understand why & how LLVM uses these
"outs"
& "ins" information from each instruction.
Any hint, please?

Thanks,
Jun
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150402/754d0b55/attachment.html>

> A question: I still dont really understand why & how LLVM uses these
"outs"
> & "ins" information from each instruction.
> Any hint, please?
It's not really necessary information for the assembler, but CodeGen
uses it to track which registers are defined and used by each
instruction. The "outs" get defined, and "ins" get used.

Cheers.

Tim.

On Fri, Apr 3, 2015 at 1:28 AM, Tim Northover <t.p.northover at gmail.com>
wrote:
> > A question: I still dont really understand why & how LLVM uses
these
> "outs"
> > & "ins" information from each instruction.
> > Any hint, please?
>
> It's not really necessary information for the assembler, but CodeGen
> uses it to track which registers are defined and used by each
> instruction. The "outs" get defined, and "ins" get
used.
>
What does CodGen track these registers (defined & used) for?


Thanks,
Jun
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150404/972d444c/attachment.html>