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

[David Fang]

Results sooner than expected:
Applying Ulrich's patches against the powerpc-darwin8 branch, the 
CodeGen/PowerPC tests (375) came clean, as did MC/PowerPC.

% bin/llvm-lit -s -v test/CodeGen/PowerPC
Testing Time: 156.69s
   Expected Passes    : 372
   Expected Failures  : 3

% bin/llvm-lit -s -v test/MC/PowerPC
Testing Time: 3.86s
   Expected Passes    : 11

Is that good enough, or do you want a full test run?  (I'll start one 
now.)

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/