[llvm-commits] Speeding up instruction selection

[Roman Levenstein]

Hi Dan,

2008/3/29, Dan Gohman <gohman at apple.com>:
>
>  On Mar 28, 2008, at 12:41 AM, Roman Levenstein wrote:
>  > Hi Dan, Hi Evan,
>  >
>  > 2008/3/28, Dan Gohman <gohman at apple.com>:
,>  >> Other than that I think this patch is ok to commit.
>  >>
>  >> I also have a comment on the overall set of changes. Right now
>  >> SDUse inherits from SDOperand, and that makes SDUse* implicitly
>  >> convertible to SDOperand*, which as you noticed is unsafe when
>  >> there's pointer arithmetic.
>  >
>  > I also thought about this issue... To experiement, I tried to make
>  > SDOperand a provate base of SDUse, to see where it would break.
>  > Basically, you cannot use the SmallVector approach afterwards.
>  >
>  >> I think it'd be better for SDUse to have an SDOperand member
>  >> instead, with associated
>  >> accessor methods.
>  > I had this idea as well.
>  >
>  >
>  >> To keep op_iterator working, it may be easiest to add
>  >> an implicit conversion from SDUse to SDOperand; this happens
>  >> be analogous to what llvm::Use does. On the other hand, an
>  >> op_iterator class wouldn't be out of place here either. What
>  >> do you think?
>  >
>  > I'm not sure this would really help much. Many places expect pointers
>  > to the array of SDOperands and unfortunately, many of them are used
>  > for real SDOperand array and for OperandList-kind of operands at the
>  > same time. Conversion of the single pointer does not help here. So, we
>  > either need SmallVector-trick at some places or we should continue
>  > using SDOperand instead of SDUse. That is, SDUse becomes the SDOperand
>  > again, as I did before.
>
>
> I'm saying we should keep the SmallVector trick (for now), and
>  that we can make it work without inheritance. Adding an implicit
>  conversion to SDOperand in SDUse:
>
>    operator SDOperand() const { return MySDOperand; }
>
>  is enough to let the SmallVector trick work. This has the
>  nice property of being the same solution that the high-level
>  Use uses.

OK. I see. This would work. But this does not solve the potential
performance problem that Evan mentioned. I have a better idea for a
solution:
Everywhere, where we pass SDOperand *, we should pass a special
iterator (or some sort of smart pointer) called e.g.  SDOperandPtr.
Internally such a pointer has a structure like this:
struct SDOperandPtr {
    SDOperand *ptr;

}

-Roman