[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)
to
Lshr, ///< Logical shift right
Ashr, ///< Arithmetic shift right
solve the problem?
Cheers,
Rafael
More information about the llvm-commits
mailing list