User Details
- User Since
- Apr 2 2014, 12:34 AM (436 w, 1 d)
Dec 21 2019
May 9 2019
Patch updates per review remarks
May 6 2019
@jdenny ? @sepavloff ?
ping
May 5 2019
Feb 9 2015
Hi Pete, I'll go on vocation from next week. And will offline till 10th of March. If you have some diffs to show, please don't hesitate for too long ;-)
Feb 2 2015
Hello Pete,
I've looked at this patch. You add support for dynamic GEPs. I was on non-llvm project for a while, and dynamic GEP is quite new thing, at least when you can use arrays as indices. It also a bit strange, that we can use only splat arrays.. Anyways, I suppose we should get vector of pointers in this case, right? Can you provide me with links, where I can read more about?
Jan 28 2015
Hi Pete,
Thanks for patch. The idea looks good, but I'm still in middle of review..
Dec 11 2014
Jul 25 2014
Hi Janne,
What exactly you'd like to merge? Did mean to use GNU style (non-Darwin) everywhere?
Jul 15 2014
Committed as r213060
Thanks for working on it!
Jul 9 2014
ping
Stepan Dyatkovskiy wrote:
Hi Nick,
can I commit patch for Björn?
Thanks!
-StepanStepan Dyatkovskiy wrote:
LGTM
Jun 27 2014
Hi Nick,
can I commit patch for Björn?
Thanks!
-Stepan
Jun 26 2014
Andrey,
do you need us to commit it?
Jun 25 2014
LGTM,
now let's wait Nick and talk to him :-)
Changes in MergeFunctions.cpp - LGTM
call-with-ranges.ll - LGTM
invoke-with-ranges.ll - read inline comment, otherwise - fine.
Yup, Renato proposed good idea. Final patch looks fine, except tiny thing, could you use single drop_front call (see inline comments)?
Jun 23 2014
Hi Björn,
Hi Andrey,
Thanks for working on it!
I think we have to keep compatibility with GAS.. So in general patch looks reasonable. May be it would be good to add some details what method does (see inline comments).
I've CCed Renato and Tim for approval.
Jun 20 2014
Committed as r211391.
Thanks!
Jun 13 2014
Hi Nick,
Can I commit it for Björn?
Thanks!
-Stepan
Jun 12 2014
Hi Bjorn,
Do you need us to commit your patch? I could do it, if Nick won't object.
Jun 11 2014
LGTM! Thanks!
Yes. Exactly ) For now, I propose to come back to initial patch; make sure tests has been fixed as I asked you in inline comments and, I think we apply it (Nick didn't object about it yesterday).
Then, after we replace ComparableFunction with new structure, you could introduce 'range' metadata merging.
Thanks for working on it!
Jun 10 2014
Hi Bjorn (sorry I don't have o-umlaut on my keyboard :-) ),
Jun 9 2014
This test has been committed with some changes as r210486. Thanks!
Hi Bjorn,
You have found really interesting point :-)
For this changes set, please, read inline comments.
Jun 5 2014
OK. I'll try to commit it for you in nearest days. All I need is meet Nick in IRC and ask about this test.
Hi Bjorn,
We have replaced "enumerate" method with "cmpValues" + "cmpConstants". That was made as part of bigger improvement.
Now getBitcast is not called. But your test is really usefull.
So I would like to ask you try your test with trunk llvm version. I think it should work now. If so, I try to organize commit for you today.
May 12 2014
So guys, how do you find this fix?
May 7 2014
I have the same opinion. IMHO, the best solution is to extend Db with information about what was parsed. But how we could solve it now? Is there any other ways to distinguish operator> from tail of "<some_operator>" ?
Apr 25 2014
Apr 24 2014
Apr 23 2014
r206951
Thanks for reviews!
Its good to me! Sean, what do you think?
I have talked with Chandler in IRC. My last suggestion contradicts LLVM design, because constants should never been removed.
So, that means we better stay on your current solution. I would be glad if you fix the tests anyway ;-)
Thanks!
Apr 22 2014
So, getBitCast creates new Value (call it C3).
C3 is not equal to C1, but it still hangs in air.
Perhaps then just as another solution, we could do the next:
- Check for bitcast possibility
- Create bitcast (C3)
- Check whether C1 is equal to C3
- Get rid of C3.
Yes, it would be good if you increase test size. So we could be sure it will run whole the comparison routines.
It doesn't return true.
Björn,
I think the fix of canLosslesslyBitcasted could be only accepted in case, when functions are not bitcastable at all. But I think they are. At least you can define such bitcast in globals. So I think, we better do our best from MergeFunctions side, keep it stable, file a bug, so then we could work on it afterwards.
Dotdash, thank you for working on it!