[MC] Requiring MCAsmInfo for MCExpr evaluation?

[Ahmed Bougacha]

Ping, any thoughts?

-Ahmed


On Tue, Apr 14, 2015 at 10:51 AM, 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?
>
> Thanks!
>
> -Ahmed