[llvm-dev] MC PowerPC 32 bit vs. 64 bit

Simon Dardis via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 8 05:04:02 PST 2016


Hi Keve,

> Dear Hal and Alex,

> thank you for the fast answer and confirming my thoughts. I am afraid my
> understanding of LLVM internals is not yet sufficient to propose
> patches, but I will certainly dig deeper into this.

> I need to first understand why introducing the additional complexity
> (doubling the GPRs and doubling the opcodes using them) had to be
> introduced in the first place. Intuitively I would have modeled the CPU
> "by the book" with 64bit GPRs and use a flag "32bit mode" to indicate
> that upper half of the register is undefined/zero.

MIPS64 introduces a complexity here, in that our arithmetic instructions have
64 bit and 32 bit versions. For the 32bit versions, the result is sign extended to
64 bits. 32 bit word loads are also sign extended. Our logical, comparison and
branch instructions operate on the full length of the register.

To date we've handled this by duplicating portions of our instruction definitions
for codegen purposes, but we have the same issue you've highlighted with
disassembly.

As Hal pointed out, it's a known issue but speaking for MIPS it's been a very
low priority issue. 

Thanks,
Simon

> 32bit mode would be either hw enforced (embedded CPUs) or software
> chosen. This would allow LLVM to understand the 64bit CPUs in 32bit as
> well (SF bit of MSR).

> "32bit mode" is a fairly common thing with 64 bit CPUs, i.e. a LLVM
> should have target agnostic fabric for this, but I have not stumbled
> upon it yet.

> Cheers,

> Keve


On 11/7/2016 6:31 PM, Hal Finkel wrote:
> Hi Keve,
>
> As you've noticed, this is not modeled currently: We should, at least in theory, be selecting the 64-bit instructions with their associated registers when in 64-bit mode. Because the assembly is ambiguous in this regard, this does not matter for the purpose of printing the resulting assembly code (it will look the same regardless) nor will it matter for the purpose of reassembling the instructions. This will likely be confusing it you're trying to do analysis on the disassembled instructions, and I'd be happy to review a patch that improves our handling here.
>
>  -Hal
>
> ----- Original Message -----
>> From: "Keve via llvm-dev" <llvm-dev at lists.llvm.org>
>> To: llvm-dev at lists.llvm.org
>> Sent: Sunday, November 6, 2016 1:24:22 PM
>> Subject: [llvm-dev] MC PowerPC 32 bit vs. 64 bit
>>
>> Hi,
>> over the past days I have been proofing a concept involving LLVM MC
>> on
>> the PowerPC target. The 32 bit part went quite ok, but i am puzzled
>> with
>> the results I get using the 64 bit target.
>> When disassembling in 64bit some instructions refer to GPRs in
>> PPC::R0
>> to PPC::R31, some refer to PPC::X0 to PPC::X31.
>> I understand that the registers are modeled with Rx referring to the
>> 32bit parts and Xx referring to the 64bit parts, but the way it looks
>> to
>> me right now is that you only get the 64bit registers if the opcode
>> is
>> available exclusively in 64bit mode.
>> I have seen that many instructions have been duplicated to support 32
>> bit registers and 64 bit register, e.g. oris vs. oris8, but the
>> disassembler does not pick the 64 bit variant.
>> PPCGenDisassemblerTables.inc does not have anything about oris8, only
>> oris.
>> As a user of the Disassembler I would expect it to return me the
>> 64bit
>> instruction referencing the 64bit registers if I ask it to
>> disassemble a
>> ppc64 target.
>>
>> Is this intended behavior or am I just missing some bit somewhere?
>> Thank you very much in advance for clarifying this.
>>
>> Cheers,
>>
>> Keve
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list