[PATCH] D142953: [RISCV] Don't use constantpool for floating-point value if the value can be easily constructed by integer sequence and a floating-point move.

[Craig Topper via Phabricator via llvm-commits]

craig.topper added a comment.

In D142953#4096475 <https://reviews.llvm.org/D142953#4096475>, @asb wrote:

> Was the motivation for adding the combines mentioned in the patch description to prevent a regression due to this change? In the absence of that, we'd typically try to keep each patch as minimal as possible.
>
> I'm curious if anyone has concerns about cases where converting an int to float might be more expensive that isn't captured in the current cost modelling - from a quick look it does seem likely to be a win unless the int/fp conversion cost is particularly high. Are there other targets that make this same choice? From a quick look at Arm it appears to use an int->float move when doing execute-only codegen but otherwise. Of course it has a wider set of options available in that ISA for efficiently materialising FP constants.

Without the vector isel changes, we'd do scalar integer lui -> scalar int to scalar fp move -> scalar fp to vector.  The vector isel changes move the integer directly to vector.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D142953/new/

https://reviews.llvm.org/D142953