[llvm-dev] trouble hoisting GlobalValues

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Fri Dec 11 14:33:00 PST 2015


----- Original Message -----
> From: "Rafael EspĂ­ndola via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Steve King" <steve at metrokings.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Friday, December 11, 2015 4:28:33 PM
> Subject: Re: [llvm-dev] trouble hoisting GlobalValues
> 
> On 11 December 2015 at 16:53, Steve King via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Hello LLVM,
> > To reduce the code-size cost of relocations, I'm trying to hoist
> > GlobalValues that are used many times.  A new pass hides each
> > hoisted
> > GV behind a BITCAST in the dominating BB.  The pass then updates
> > users
> > with the output of the BITCAST.  This pass works properly AFAICT.
> >
> > The problems come in instruction selection.
> > SelectionDAGBuilder::visitBitCast() treats the BITCAST as a no-op
> > and
> > eventually users of the GV fold the relocation as if hoisting never
> > happened.  Experiments turning the BITCAST into a copytoreg failed
> > and
> > anyway I feel like I'm just shooting in the dark.
> >
> > Can anyone can suggest a strategy for lowering a hoisted GV?  The
> > end
> > result should be that the GV materializes as a simple
> > move-immediate
> > to register.

Also, something similar-sounding to this is done in lib/Transforms/Scalar/ConstantHoisting.cpp

 -Hal

> 
> Nothing simple. One possibility would be to make constants explicitly
> materialized. Something like:
> 
> https://github.com/apple/swift/blob/master/docs/SIL.rst#global-addr
> 
> Which would also be useful for architectures where some constants are
> expensive to place in a register.
> 
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

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


More information about the llvm-dev mailing list