Fwd: [RFC, PowerPC, Darwin] Clean up generation of ha16() / lo16() markers

[David Fang]

Hi Hal, Ulrich,
 	Sure, I'll gladly test this out on the powerpc-darwin8 branch 
(trunk/master doesn't build as-is).  Give it an hour+ to build.  Is there 
a specific set of regression tests I can run?  (I could just run all llvm 
tests, but that would take longer, 3+ hrs.)  Which tests in the testsuite 
cover the behavior that would be affected by this patch? Is 
test/CodeGen/PowerPC/* sufficient to 'pass'?

Fang

> Can you please test this on your Darwin system?
>
> Thanks again,
> Hal
>
> ----- Forwarded Message -----
> From: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
> To: llvm-commits at cs.uiuc.edu
> Cc: "Hal Finkel" <hfinkel at anl.gov>
> Sent: Wednesday, May 15, 2013 11:01:58 AM
> Subject: [RFC, PowerPC, Darwin] Clean up generation of ha16() / lo16() markers
>
>
> Hello,
>
> when targeting the Darwin assembler, we need to generate markers ha16() and
> lo16() to designate the high and low parts of a (symbolic) immediate.  This
> is necessary not just for plain symbols, but also for certain symbolic
> expression, typically along the lines of ha16(A - B).  The latter doesn't
> work when simply using VariantKind flags on the symbol reference.
>
> This is why the current back-end used hacks (explicitly called out as such
> via multiple FIXMEs) in the symbolLo/symbolHi print methods.  I'd like to
> get rid of this special treatment as a first step towards getting rid of
> symbolLo/symbolHi itself.  This is interesting because it will allow
> non-standard (but legal) use of the @l and @hi markers, e.g. to do
> "lis ..., symbol at l"  (which is valid if unusual assembler, but will not be
> handled correctly by the llvm assembler right now).
>
> The attached patch uses target-defined MCExpr codes to represent the Darwin
> ha16/lo16 constructs, following along the lines of the equivalent solution
> used by the ARM back end to handle their :upper16: / :lower16: markers.
> This allows us to get rid of special handling both in the symbolLo/symbolHi
> print method and in the common code MCExpr::print routine.  Instead, the
> ha16 / lo16 markers are printed simply in a custom print routine for the
> target MCExpr types.
>
> I don't have a live Darwin system to test on, but the Darwin assembler
> tests in the test suite all still pass.
>
> Does this look reasonable?
>
> Bye,
> Ulrich
>
> (See attached file: diff-reloc-mcexpr)

-- 
David Fang
http://www.csl.cornell.edu/~fang/