llvm dev - Mar 2014 - [LLVMdev] CFI directives and register names?

Hi everyone,

I don't *really* understand CFI directives, so hopefully someone who does
can help explain what needs to be done:

On PowerPC we have a set of floating-point registers (f0, f1, f2, etc.) and we
produce CFI directives for them like this:

  .cfi_offset f0, 300

and, moreover, test/MC/PowerPC/ppc64-regs.s ensures that for every such
directive we can spit it back out again correctly. Some more-recent cores
support an ISA extension which adds new super registers for each of these
floating-point registers. According to gcc, these super registers share the same
DWARF numbers as their traditional subregister. Simply adding these new
registers, with the corresponding DWARF numbers, to the backend causes a change
in how these CFI directives are produced. Specifically, when:

  .cfi_offset f0, 300

is run through llvm-mc --show-encoding is outputs:

  .cfi_offset vs0, 300

which has the name of the super register (similarly, the actual assembly output
from llc also now contains the super registers in the CFI directives). I have a
few questions:

 1. Is this a correctness problem or does it just look weird?

 2. What is the best way to fix this?

When I chatted briefly with Raphael this morning, he suggested that we might
need to change the TargetRegistry::RegisterMCRegInfo callback to take
SubtargetInfo object. I suppose we could move the DWARF flavor determination
into SubtargetInfo? I think in practice this means making createMCRegInfo take a
MCSubtargetInfo*.

Thanks in advance,
Hal

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

----- Original Message -----
> From: "Hal Finkel" <hfinkel at anl.gov>
> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Tuesday, March 11, 2014 11:13:25 AM
> Subject: [LLVMdev] CFI directives and register names?
> 
> Hi everyone,
> 
> I don't *really* understand CFI directives, so hopefully someone who
> does can help explain what needs to be done:
> 
> On PowerPC we have a set of floating-point registers (f0, f1, f2,
> etc.) and we produce CFI directives for them like this:
> 
>   .cfi_offset f0, 300
> 
> and, moreover, test/MC/PowerPC/ppc64-regs.s ensures that for every
> such directive we can spit it back out again correctly. Some
> more-recent cores support an ISA extension which adds new super
> registers for each of these floating-point registers. According to
> gcc, these super registers share the same DWARF numbers as their
> traditional subregister. Simply adding these new registers, with the
> corresponding DWARF numbers, to the backend causes a change in how
> these CFI directives are produced. Specifically, when:
> 
>   .cfi_offset f0, 300
> 
> is run through llvm-mc --show-encoding is outputs:
> 
>   .cfi_offset vs0, 300
> 
> which has the name of the super register (similarly, the actual
> assembly output from llc also now contains the super registers in
> the CFI directives). I have a few questions:
> 
>  1. Is this a correctness problem or does it just look weird?
> 
>  2. What is the best way to fix this?
To partially answer my own question, I just noticed DwarfRegAlias. Using that
seems to provide a way to tag the DWARF numbers of the new super registers
without changing the name that is printed.

 -Hal
> 
> When I chatted briefly with Raphael this morning, he suggested that
> we might need to change the TargetRegistry::RegisterMCRegInfo
> callback to take SubtargetInfo object. I suppose we could move the
> DWARF flavor determination into SubtargetInfo? I think in practice
> this means making createMCRegInfo take a MCSubtargetInfo*.
> 
> Thanks in advance,
> Hal
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory