llvm dev - May 2014 - [LLVMdev] Guidance on using pointers vs. references for function arguments

On May 26, 2014, at 9:15 PM, Chandler Carruth <chandlerc at google.com>
wrote:
> 
> On Mon, May 26, 2014 at 8:45 PM, Chris Lattner <clattner at
apple.com> wrote:
> Chandler, Andy's recollection is correct.
> 
> I was personally infatuated by this idea and pushed it through a ton of the
LLVM IR APIs (this was many years ago, (in the pre-1.0 days, and then again
early in Clang's development because I'm a slow learner).  It led to all
sorts of weird cases where some arguments to IR objects would be taken by
reference and some by pointer.  It made it impossible to remember whether a
given function took a pointer or a reference, and made for absolute madness
trying to program against the APIs.  It got to the point where literally you had
to do a build and just add the missing &/*'s to get the build to go
through.
> 
> I didn't doubt any of Andy's recollection here, and it seemed like
we were largely in agreement...
> 
> Anyways, while inconsistency such as you describe between pointer and
reference arguments can be quite frustrating (as I see it was for you), at least
LLVM is still pretty stunningly inconsistent to this day. I also don't find
it to be a significant burden.
It is true in parts, but not broadly.  If you look at LLVM, for example, pretty
much all of the IR stuff takes pointers, even in places where they should
"obviously" be references: IRBuilder, ConstantArray::get and other
factories, and many others.  Likewise pretty much the entire Clang AST library
is defined in terms of pointers.

It is true that passes and other local stuff is wildly inconsistent, but the
damage of that is far less than affecting the core IR/AST.
> Ultimately, (as I said in my prior email) I don't think there is a
problem to solve here because I don't think that any of these things are
actively "bad". Maybe its just the devs I know who don't really
have trouble here, but its not one of the complaints I hear from others or have
myself in day-to-day development.
> 
> If mixing pointers and references for the same type in LLVM's APIs is a
serious problem in your mind, what is your concrete suggestion? What should the
end state look like?
I'm not really sure that we need to "solve" this problem.  Can you
restate exactly what the problem is?  We don't all need the compiler to have
perfectly identical code in every pass, for example.

That said, if I were to lay down a rule, I think the right general rule would
be: pointers for "classes" everywhere, references for value types, and
pass by value when it is >= the efficiency of pass by value for value types.

That said, I still don't see a huge problem being solved here...

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140526/59ed089b/attachment.html>

On May 26, 2014, at 9:31 PM, Chris Lattner <clattner at apple.com> wrote:
> That said, if I were to lay down a rule, I think the right general rule
would be: pointers for "classes" everywhere, references for value
types, and pass by value when it is >= the efficiency of pass by value for
value types.
Sorry, I meant:

> That said, if I were to lay down a rule, I think the right general rule
would be: pointers for "classes" everywhere, references for value
types, and pass by value when it is >= the efficiency of pass by reference
for value types.
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140526/9c5cfe2a/attachment.html>

On Mon, May 26, 2014 at 9:31 PM, Chris Lattner <clattner at apple.com>
wrote:
> Ultimately, (as I said in my prior email) I don't think there is a
problem
> to solve here because I don't think that any of these things are
actively
> "bad". Maybe its just the devs I know who don't really have
trouble here,
> but its not one of the complaints I hear from others or have myself in
> day-to-day development.
>
> If mixing pointers and references for the same type in LLVM's APIs is a
> serious problem in your mind, what is your concrete suggestion? What should
> the end state look like?
>
>
> I'm not really sure that we need to "solve" this problem. 
Can you restate
> exactly what the problem is?  We don't all need the compiler to have
> perfectly identical code in every pass, for example.
>
We have to be talking past each other. Let me re-quote my email:

"I don't think there is a problem to solve here ..."

And then your email:

"That said, I still don't see a huge problem being solved here..."

We're in agreement about this not being worth laying down rules, even we
disagree about what the rules should be were we to need strict ones.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140526/93cee1e8/attachment.html>

On May 26, 2014, at 9:43 PM, Chandler Carruth <chandlerc at google.com>
wrote:
> 
> On Mon, May 26, 2014 at 9:31 PM, Chris Lattner <clattner at
apple.com> wrote:
>> Ultimately, (as I said in my prior email) I don't think there is a
problem to solve here because I don't think that any of these things are
actively "bad". Maybe its just the devs I know who don't really
have trouble here, but its not one of the complaints I hear from others or have
myself in day-to-day development.
>> 
>> If mixing pointers and references for the same type in LLVM's APIs
is a serious problem in your mind, what is your concrete suggestion? What should
the end state look like?
> 
> I'm not really sure that we need to "solve" this problem. 
Can you restate exactly what the problem is?  We don't all need the compiler
to have perfectly identical code in every pass, for example.
> 
> We have to be talking past each other. Let me re-quote my email:
> 
> "I don't think there is a problem to solve here ..."
> 
> And then your email:
> 
> "That said, I still don't see a huge problem being solved
here..."
> 
> We're in agreement about this not being worth laying down rules, even
we disagree about what the rules should be were we to need strict ones.
Chandler, I violently agree with you!

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140526/b40025c8/attachment.html>