llvm dev - Dec 2017 - target porting : objdump is not giving proper registers.

Hi,
we have seen proper register numbers when we have generated assembly files
through clang but
when we generated dump files from object file then we didn't see expected
register numbers.

Note : all registers are replaced with R0


















*Disassembly of section .text:00000000 <main>:   0:   3000ffcc       
addik
  r0, r0, -52   4:   f8000000        swi     r0, r0, 0   8:   10000000
   addk    r0, r0, r0   c:   f800002c        swi     r0, r0, 44  10:
3000000a        addik   r0, r0, 10  14:   f8000028        swi     r0, r0,
40  18:   3000000f        addik   r0, r0, 15  1c:   f8000024        swi
r0, r0, 36  20:   e8000028        lwi     r0, r0, 40  24:   6000000f
 muli    r0, r0, 15  28:   f8000020        swi     r0, r0, 32  2c:
10000000        addk    r0, r0, r0  30:   e8000000        lwi     r0, r0,
0  34:   b60f0008        rtsd    r15, 8  38:   30000034        addik   r0,
r0, 52*

I am not able to find where it went wrong.could you help me with some notes.

Thanks,
Mahesh B
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171211/ebd506cd/attachment.html>

Hi Mahesh,

On 11 December 2017 at 06:41, Mahesh Bodapati via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> we have seen proper register numbers when we have generated assembly files
> through clang but when we generated dump files from object file then we
didn't see expected
> register numbers.
I assume this is a backend you're writing? Those encodings have a lot
of 0s in them, so I'm guessing the object file is what's wrong rather
than the dumper.

Have you made sure you have fields in your instructions whose names
match the registers in the (outs) and (ins) and get assigned to the
"Inst" bitfield? That's how TableGen knows where to encode each
register.

You should look for calls to getMachineOpValue in
build/lib/Target/XYZ/XYZGenMCCodeEmitter.inc, both in the source and
with a debugger to make sure it's actually being called and doing what
you expect.

Cheers.

Tim.

Hi Tim,
Thanks for your observations.It seems I have missed adding encoding values
for registers.

Thanks,
Mahesh B

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Dec 11, 2017 at 1:27 PM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> Hi Mahesh,
>
> On 11 December 2017 at 06:41, Mahesh Bodapati via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > we have seen proper register numbers when we have generated assembly
> files
> > through clang but when we generated dump files from object file then
we
> didn't see expected
> > register numbers.
>
> I assume this is a backend you're writing? Those encodings have a lot
> of 0s in them, so I'm guessing the object file is what's wrong
rather
> than the dumper.
>
> Have you made sure you have fields in your instructions whose names
> match the registers in the (outs) and (ins) and get assigned to the
> "Inst" bitfield? That's how TableGen knows where to encode
each
> register.
>
> You should look for calls to getMachineOpValue in
> build/lib/Target/XYZ/XYZGenMCCodeEmitter.inc, both in the source and
> with a debugger to make sure it's actually being called and doing what
> you expect.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171212/f5ea7b9a/attachment.html>