LRB midpath code quality

[Roman Kennke]

Am 5. März 2019 09:12:38 MEZ schrieb Roland Westrelin <rwestrel at redhat.com>:
>
>> Also, it seems weird that the null-check is after the in-cset-check,
>but 
>> not before. It's probably a left-over from null-check-cloning that 
>> should actually disappear too?
>
>It looks like it's not converted to an implicit null check for some
>reason.

Do we even need a null check there, implicit or not? There should be a null-check before in-cset-check which apparently got eliminated, in any case we would blow up there, no? No way we would even get to the later null-check with an actual null.

Maybe this causes the register hiccup in return paths? Or are we wiring up the wrong nodes into the phi? Uncasted_val vs. val?

Thanks, Roman

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.