[MC] Requiring MCAsmInfo for MCExpr evaluation?

Ahmed Bougacha ahmed.bougacha at gmail.com
Tue Apr 14 10:51:38 PDT 2015


Hi all,

Currently, we evaluate MCBinaryExprs as int64_t.  The lack of
flexibility is sometimes problematic (PR20980, PR23227).  There's an
old FIXME in MCExpr:

    // FIXME: We need target hooks for the evaluation. It may be limited in
    // width, and gas defines the result of comparisons and right shifts
    // differently from Apple as.

I'm trying to figure out a solution.

The first thing to do would be to have targets decide which behavior
they want, and MCAsmInfo seems like the obvious place.

The problem is how to wire that to MCExpr.  We can get MCAsmInfo
indirectly from most variants of
MCExpr::EvaluateAs{Relocatable,Absolute}, but there's:

  bool EvaluateAsAbsolute(int64_t &Res) const;

for which we can't.  The comment above says this about the lack of
MCAsmLayout/MCAssembler:

    If not given, then only non-symbolic expressions will be evaluated.

Which sounds reasonable, but isn't enough.

My question: is there any objection to changing all MCExpr::Evaluate*
methods to have at least an MCAsmInfo parameter?

I looked around, and there's a few places where we don't have access
to that currently (MCAsmBackends, mostly), so this entails other
changes as well.  I couldn't come up with an argument against this
though, so, what do people think?

Thanks!

-Ahmed



More information about the llvm-commits mailing list