[PATCH] PowerPC: Resolve constant at l/h/ha without fixups
rafael.espindola at gmail.com
Tue Mar 11 13:28:31 PDT 2014
On 11 March 2014 15:43, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote:
> as noticed in a recent discussion with Roman, while we support constructs
> like "1234 at l" now, this still generates a fixup, where it would be
> preferable to resolve the expression directly without fixup or relocations.
> The reason why this doesn't work is the !Layout test in
> if (!Layout || !getSubExpr()->EvaluateAsRelocatable(Value, *Layout))
> return false;
> EvaluteAsRelocatableImpl may be called from various original MCExpr
> routines, including EvaluateAsAbsolute. In some of these cases, Layout is
> NULL. However, we still can (and should) simplify the target expression if
> the subexpression is in fact a constant.
> The generic EvaluteAsRelocatableImpl recurses on subexpressions using a
> generic implementation that does not require a non-NULL Layout:
> bool MCExpr::EvaluateAsRelocatableImpl(MCValue &Res,
> const MCAssembler *Asm,
> const MCAsmLayout *Layout,
> const SectionAddrMap *Addrs,
> bool InSet) const
> Unfortunately, this is "protected", and therefore cannot be used from the
> PPCMCExpr code (and we don't have all the required arguments either, since
> they're not passed to the MCTargetExpr implementation). I've tried
> unsuccessfully to change common code along these lines while still keeping
> the routine protected ... any suggestions how to do that?
> In any case, here is a PowerPC-only patch that still fixes the problem for
> us; this is basically along the lines of the hack Roman originally
> suggested. I guess we can still put this in for now until a cleaner common
> code solution is implemented ... Thoughts?
This is only an issue when printing assembly, right? When producing an
object file we should have an Layout available.
More information about the llvm-commits