[llvm-dev] Endianness for multi-word types

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Tue Dec 1 15:09:52 PST 2015


----- Original Message -----
> From: "Tim Northover" <t.p.northover at gmail.com>
> To: "Tim Shen" <timshen at google.com>
> Cc: "Yunzhong Gao" <yunzhong_gao at playstation.sony.com>, "Hal Finkel" <hfinkel at anl.gov>, llvm-dev at lists.llvm.org,
> "Nemanja Ivanovic" <nemanja.i.ibm at gmail.com>
> Sent: Tuesday, December 1, 2015 4:00:15 PM
> Subject: Re: [llvm-dev] Endianness for multi-word types
> 
> On 1 December 2015 at 13:41, Tim Shen via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > As a simple solution, when see a LLVM IR bitcast, instead of
> > generating
> > (ISD::BITCAST x), can we generate (exchange_hi_lo (ISD::BITCAST x))
> > instead?
> 
> An LLVM bitcast is defined to be equivalent to a store/load pair.
> Changing that for ISD::BITCAST would be very surprising, and  I
> wouldn't recommend it. It's a very useful invariant for reasoning
> about what should happen.

Changing the semantics of ISD::BITCAST seems unfeasible.

> I have a feeling that you will run into more cases in the DAG
> combiner where you want
> to add special handling codes for ppc_fp128, and I also feel that
> this type is peculiar
> enough that other backend owners upon trying to add more DAG combiner
> passes are
> likely to miss adding the special handling codes as they probably
> should.
> 
> 
> This is what I was worrying about.
> 

This is a concern, but it is not new, nor unique to ppc_fp128. When writing code in DAGCombine (or any other part of the common code generator) you need to be aware of the requirements of parts of the IR used only by other targets. ppc_fp128 is not even the only custom FP type for which we have special handling (we have x86_fp80 too). While I agree that having some abstraction over these custom types could make things easier (if designed correctly), ppc_fp128 is part of the IR as it stands, and everyone needs to be aware of it when working with FP code that makes assumptions about the FP representation. Luckily, there are not actually a lot of such places.

 -Hal

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


More information about the llvm-dev mailing list