[PATCH] D91174: [Support] Introduce a new InstructionCost class

Christopher Tetreault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 9 11:54:41 PST 2020


ctetreau added inline comments.


================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:7167
   case Instruction::ExtractValue:
-    return TTI.getInstructionCost(I, TTI::TCK_RecipThroughput);
+    return *(TTI.getInstructionCost(I, TTI::TCK_RecipThroughput).getValue());
   default:
----------------
ctetreau wrote:
> RKSimon wrote:
> > Is it a good idea to always "dereference" optionals like this?
> In principle, "no". However, my assumption is that this function will eventually be changed to return InstructionCost. For now, all we can do is assert that it's valid.
> 
> a nice assert would be nice, but Optional::operator* does assert that there's a value, so a debugger will break in a useful location if this code ever tries to unwrap a none
I suppose maybe we ought to be setting a good example with the introduction of this new type. If it always unconditionally dereferences the Optional from day one, monkey-see-monkey-do will ensure that this is done everywhere.

I think adding an actual assert, optionally  a FIXME would be good enough.


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

https://reviews.llvm.org/D91174



More information about the llvm-commits mailing list