[MC] Requiring MCAsmInfo for MCExpr evaluation?

Rafael EspĂ­ndola rafael.espindola at gmail.com
Wed Apr 22 14:43:53 PDT 2015

On 14 April 2015 at 13:51, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote:
> 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?

Looks like we have to store more information in the expressions
themselves. Would changing

 Lhr,  ///< Shift right (arithmetic or logical, depending on target)


 Lshr,  ///< Logical shift right
 Ashr,  ///< Arithmetic shift right

solve the problem?


More information about the llvm-commits mailing list