[llvm-commits] PATCH: new Value::getThruSplat API

Nick Lewycky nlewycky at google.com
Fri Oct 29 21:50:30 PDT 2010


On 29 October 2010 21:34, Chris Lattner <clattner at apple.com> wrote:

> On Oct 29, 2010, at 7:28 PM, Nick Lewycky wrote:
>
> Which reminds me; your current patch doesn't handle vector
>> ConstantAggregateZero.
>>
>
> Good catch! Updated patch attached.
>
>
> Some random comments:
>
> +  /// getThruSplat - This method returns the singular splat value held by
> this
> +  /// value if it is a ConstantVector holding a splat, otherwise it
> returns
> +  /// itself.
>
> This description is confusing to me.  How about something like:
>
> If the current value is a constant vector where all of the elements have
> the same value, return that value.  Otherwise, return the current value.
>

Much better. Thanks!


> Also, the way it is used is confusing.  Why not name it "getSplatElement"
> and have it return null on failure?
>

Because I want to preserve the pattern of a declaring a single variable
inside an if-statement with a dyn_cast. I'm planning to find and update code
which currently does that with a test for ConstantInt/FP and don't want to
add lots of this pattern:

  Value *V = value;
  if (ConstantVector *CV = dyn_cast<ConstantVector>(V))
    if (Constant *Splat = CV->getSplatValue())
      V = Splat;
  if (ConstantInt *CI = dyn_cast<ConstantInt>(V)) {
    ...

all over. If getSplatElement() returned NULL instead of "this" then I would
only be able to remove one line of that (the test for ConstantVector).

I guess I don't really understand what makes the replacement code confusing.

+Value *Value::getThruSplat() {
> +  switch (getValueID()) {
>
> This would be more natural and elegant written with two dyncasts instead of
> a switch.  The premature optimization isn't worth it, and llvm at least will
> turn the two dyncasts into a switch anyway.
>

Okay!

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101029/455e1802/attachment.html>


More information about the llvm-commits mailing list