- User Since
- Jul 17 2015, 4:04 PM (166 w, 1 d)
Thu, Sep 20
Address @tejohnson comment by adding NFCs to commit msg and summary.
Mon, Sep 17
Ping 2X. Thanks!
Thu, Sep 13
collect some numbers on sqlite3.c
Wed, Sep 12
LGTM. @efriedma, does this look good to you ? I think we have to have similar treatments for memcpyopt in the past.
Tue, Sep 11
Fri, Aug 31
This looks good to me. I will let @courbet to have the final say here.
Fri, Aug 24
Aug 24 2018
Aug 22 2018
Aug 20 2018
Thanks!. The approach I am considering is to bring in something, like a stub (e.g. the declaration completely unmapped, we cant map it fully anyways) and eventually using it as a handle to RAUW when we have properly mapped in the SGV. Do you think this would work ?
@evgeny777 Do you mind I give this bug a try ? Thanks.
Aug 12 2018
I dumped the Composite right after the 2nd file is merged. Things look good except the DITemplateValueParameter debuginfo looks a bit odd. Does this look correct to you ?
Aug 5 2018
Jul 26 2018
Jul 21 2018
Jul 19 2018
Jul 18 2018
Jul 16 2018
@fhahn Thank you for doing this. This is not a blocking issue for us. But it would be nice to have it fixed (for us and the possibly other users of LLVM in general). If you and @davide agree we should do this before having a real fix. I can write a test and land this. Otherwise, I am fine waiting for the real fix.
Address comments. Thanks @hfinkel
Jul 14 2018
This brings about 20ms - 25ms out of ~20s when compile sqlite3.c
Update diff addressing all of @hfinkel comments.
@hfinkel I get what you mean. Basically moving the IntrinsicInst check inside the call does not result us doing extra work when processing IntrinsicInst as we essentially do the same things in the dyn_cast<IntrinsicInst>. I will update the diff accordingly.
Address some of @hfinkel suggestions.
Thank you for taking a look at this code. I agree we should definitely "else" the StoreInst check and I have observed improvements in Xcode Instrument for doing so.
Jul 13 2018
Friendly Ping. Are there any problems with this patch ? Do I need to collect more #s ?
Jul 9 2018
Jun 22 2018
Hi @brzycki. This is a deficiency in a feature we already have. In jump threading, when we can tell all the predecessors of a block go to the same destination. we do not need to thread, we can just fold the terminator of the block. This has less impact on the CFG and also we do not have the problem of not being able to jump threading because the block can not be duplicated.
Jun 21 2018
Jun 18 2018
Address @asbirlea comments
Jun 17 2018
I think this makes sense. Except Jumpthreading needs to be modified to make sure iterator is valid after merging. I can work on the jump threading part once this lands and if you do not mind @brzycki.
Jun 16 2018
Remove some duplicate code.
Jun 14 2018
Handle when all destinations are null (i.e. UNDEF value). There is a slight change in pr22086.ll this is due
to we do not run SimplifyInstructionsInBlock after folding (we run after threading).
I am having some trouble with arc. Created this diff accidentally. Its a duplicate of https://reviews.llvm.org/D48181
Jun 12 2018
@davide @fhahn I am sorry that I cant provide the source code. But one of the cases that resulted in chasing up the chain a lot I can see came from a sequence of object declarations & initializations (constructors which can throw). And they cascaded into a block with 2 predecessors.
Jun 8 2018
May 1 2018
And I think adding an assert to check against queries w.r.t. dominance makes sense.
Apr 30 2018
Apr 24 2018
Apr 23 2018
Simplify test. I could not get rid of the inttoptr though.
Apr 22 2018
Remove empty lines.
Apr 17 2018
Apr 14 2018
Apr 13 2018
Apr 12 2018
Apr 9 2018
Address stylistic comments.
Apr 8 2018
Apr 6 2018
@courbet Ping. Thanks
Update checks in a test case.
Simplify how split instructions are moved.
Mar 27 2018
Update an assert.