[MC] Requiring MCAsmInfo for MCExpr evaluation?

[Rafael Espíndola]

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)

to

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

solve the problem?

Cheers,
Rafael