[MC] Requiring MCAsmInfo for MCExpr evaluation?

Ahmed Bougacha ahmed.bougacha at gmail.com
Tue Apr 21 18:03:46 PDT 2015

Ping, any thoughts?


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

More information about the llvm-commits mailing list