[llvm] r187819 - Change private functions of LTOCodeGenerator from ret-false-on-succ to ret-true-on-succ.

Eric Christopher echristo at gmail.com
Tue Aug 6 15:31:11 PDT 2013


On Tue, Aug 6, 2013 at 3:29 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:
>
> On 8/6/13 3:27 PM, Eric Christopher wrote:
>>
>> On Tue, Aug 6, 2013 at 3:24 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:
>>>
>>> On 8/6/13 3:19 PM, Eric Christopher wrote:
>>>>
>>>> On Tue, Aug 6, 2013 at 3:14 PM, Shuxin Yang <shuxin.llvm at gmail.com>
>>>> wrote:
>>>>>
>>>>> Chris's comment has been authorative. His comment was "I don't have
>>>>> strong
>>>>> opinion", meaning
>>>>> I can take advantage of any loophole. I don't care if we codify this
>>>>> std
>>>>> or
>>>>> not.
>>>>>
>>>> I suppose that works as "authoritative". And you may not care, but if
>>>> you want consistency then you should propose something. Also, if
>>>> you're just changing the private functions then that means that code
>>>> base isn't consistent, just the private ones are. That's even more
>>>> confusing than just documenting what each function returns on success.
>>>>
>>>> -eric
>>>>
>>> The  private ones are just part of my change, I'm going to change public
>>> functions as well.
>>> The LTOCodeGenerator is just a local class, as it dance behind the
>>> lto_xxxx
>>> APIs. I don't
>>> want to touch these APIs, I only negate return value of the "local" class
>>> and make sure all
>>> its functions are consistent. Those lto_xxx APIs have to serve as adapter
>>> between
>>> return-on-succ and return-on-false.
>>>
>> That sounds painful and confusing, why not just change your code to
>> match the code you are attempting to integrate with?
>>
> Because it is more painful and confusing than just changing the
> LTOCodeGenerator.
>

To whom? The code that you'd be changing hasn't been committed yet.

-eric



More information about the llvm-commits mailing list