<div class="gmail_quote">On 27 October 2010 17:42, Dan Gohman <span dir="ltr"><<a href="mailto:gohman@apple.com">gohman@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
On Oct 27, 2010, at 4:53 PM, Nick Lewycky wrote:<br>
<br>
> On 27 October 2010 10:57, Dan Gohman <<a href="mailto:gohman@apple.com">gohman@apple.com</a>> wrote:<br>
><br>
> On Oct 26, 2010, at 11:34 PM, Nick Lewycky wrote:<br>
><br>
> > This patch adds a new method on Value called getThruSplat() which returns the splatted value iff this is a ConstantValue with a splat, or 'this' otherwise. I demonstrate its usage by updating InstructionSimplify to uniformly handle splat vectors alongside ConstantInt values.<br>


><br>
> Looks reasonable to me.<br>
><br>
> How about "getScalarValue" instead of "getThruSplat"?<br>
> I don't have strong opinions about it though.<br>
><br>
> ConstantArray and ConstantStruct aren't scalar and this method could return those. For that matter, it could even return a vector, constant or not.<br>
><br>
> My concern is to make very sure that this is the API we really want. Are we sure that "dyn_cast<ConstantInt>(V->getThruSplat())" doesn't do any more work than the minimum (or at least, that the compiler can't optimize away)? And is it okay to put this work on the lookup side? We will do this test more often this way than if we did the work at the point of creation, which is the pattern we follow in the rest of LLVM.<br>


<br>
</div>With the current class hierarchy, that dyn_cast really is needed. The splat value<br>
could theoretically be some crazy unfoldable ConstantExpr.</blockquote><div><br></div><div>Sure, but if the input is a ConstantStruct for example, will its value ID be loaded and tested twice? I'm relying on jump threading which both GCC and LLVM ought to be capable of (nowadays; I'm sure llvm didn't use to be able to do it).</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> It might be nice to<br>
push it into the API though, and have<br>
  ConstantInt *getAsConstantInt();<br>
  ConstantFP *getAsConstantFP();<br>
instead though, if you're going to be doing this a lot.<br></blockquote><div><br></div><div>I'm not a fan, it sounds as though you could get any Value as a ConstantInt/FP which just doesn't make sense.</div><div>

<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> The most radical alternative API would be to factor out a common base that represents a ConstantInt+ConstantVector(with splat) and another for ConstantFP+ConstantVector(with splat), then teach ConstantVector to return such a splatted CV from its getter. Sadly if you follow this through to its conclusion, you end up using multiple inheritance in the Constant hierarchy which causes all sorts of forms of pain.<br>


<br>
</div>I agree, don't do MI. But I think if you wanted to take this approach, you could<br>
make ConstantInt and ConstantFP capable of having vector types, but not be<br>
subclasses of ConstantVector. ConstantVector would just be for cases where it's<br>
really necessary to have an array of operands. This sounds like a big and scary<br>
change, though there are some reasons it might not have to be.<br>
<br>
With this approach, vector ConstantAggregateZero could go away.<br></blockquote><div><br></div><div>Doing that would force me to audit every single use of ConstantInt and ConstantFP to make sure they're okay with splat vectors instead of real int's/fp's, and adding tests on the type if necessary. Do you think that would be a better API at the end of the day? My proposed patch would be more of an opt-in approach.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Which reminds me; your current patch doesn't handle vector ConstantAggregateZero.<br></blockquote>
<div>
<br></div><div>Good catch! Updated patch attached.</div><div><br></div><div>Nick</div></div>