[llvm-dev] Dealing with information loss for widened integer operations at ISel time

[Friedman, Eli via llvm-dev]

On 12/13/2018 6:25 AM, Alex Bradbury wrote:
> There's also likely to be cases where you want to calculate the demanded bits
> in order to determine if e.g. a W-suffixed instruction can be selected for
> `(somoeop (zexti32 GPR:$rs1), (zexti32 GPR:$rs2))`. This is easy to match if
> the SelectionDAG contains an explicit `sext_inreg` of the result. But if not,
> you'd need to check whether the upper 32 bits are actually demanded or not.

Could you describe more specifically where this matters?  I would guess 
the W-suffixed instructions aren't actually any cheaper, in general, 
than non-W-suffixed instructions, so there's no point to using W forms 
if you don't need the sign extension. Unless MULW has lower latency than 
MUL on some CPU?

> Any thoughts on how to best handle these cases? For the shifts I could
> obviously introduce a target-specific SelectionDAG node, but then I'd lose the
> benefit of most of the target-independent DAG combines. A target DAG combine
> could custom lower the shift amount. e.g. converting (shl val, shamt) to (shl
> val, (and shamt, 31)) before it gets widened to i64. But this runs the risk
> of introducing an unnecessary AND operation if it turns out that the
> SelectionDAG node is transformed by the time it reaches instruction selection.
> So for this particular issue with shifts, introducing a target-specific WasI32
> node and converting to (shl val, (WasI32 shamt)) in a target DAG combine looks
> plausible.

You can represent "WasI32" using AssertZext i5.  That seems like a 
reasonable approach.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project