similar to: Redundant promotion of integer values in x86 target

Sanjay, Kevin, Thank you for your reply. Kevin, I wonder if you are still working on it and have a plan to submit your changes for the review. Thanks, Taewook From: "Smith, Kevin B" <kevin.b.smith at intel.com<mailto:kevin.b.smith at intel.com>> Date: Monday, February 1, 2016 at 3:30 PM To: 'Sanjay Patel' <spatel at rotateright.com<mailto:spatel at

Hi Taewook - There's a discussion about the underlying x86 micro-arch details here: http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/167221 The conclusion was that we should change how we currently handle these, but we don't want to regress the case that was addressed by: http://reviews.llvm.org/rL195496 There are open bugs with more discussion related to this:

It is $target dependent. I’m curious what makes you think it is $host dependent. Thanks, Taewook On 3/3/17, 5:10 PM, "Jonathan Roelofs" <jonathan at codesourcery.com> wrote: On 3/3/17 12:23 PM, Taewook Oh wrote: > Thanks Jon. Actually I tried “x86_64-linux”, but it makes the test “Unsupported” from my linux machine, and it was because my test is under

Thanks Jon. Actually I tried “x86_64-linux”, but it makes the test “Unsupported” from my linux machine, and it was because my test is under clang, not llvm. It seems that clang doesn’t support “x86_64-linux” yet. Thanks again! Best, Taewook On 3/3/17, 10:57 AM, "Jonathan Roelofs" <jonathan at codesourcery.com> wrote: On 3/3/17 11:46 AM, Taewook Oh via llvm-dev

No problem! I want to make sure you aren't blocked on trying ThinLTO. Thanks, Teresa On Mon, Aug 15, 2016 at 2:50 PM, Taewook Oh <twoh at fb.com> wrote: > Hello Teresa, > > > > Sorry I was working on another LLVM issue that more urgent for us, so > didn’t have much time to work on smaller test case. I’ll try the new API > and see if the issus is gone. Thanks! >

Hi Taewook, I had a better fix for this approved (D23015), but when I went to merge this with the new LTO API I committed for pcc last week I discovered that his new API already has the same effect. I will update the bug with this info as well. Can you confirm that with a compiler built after 278338 that this problem no longer occurs? Also, any luck on a smaller test case for the -g issue? Now

and by "right thing" i mean it can hoist if you want and it can prove it will not extend the live range. Note that VBE (very busy expressions) is a code size optimization only. It does not save time. On Tue, Feb 9, 2016 at 12:26 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > This GVN does not do that, this is correct. It is a very simple GVN. All > phi nodes are

Yes, if I drop the debug flag then the original problem (assertion failure) comes back. Thanks, Taewook From: Teresa Johnson <tejohnson at google.com> Date: Friday, July 29, 2016 at 3:52 PM To: Taewook Oh <twoh at fb.com> Cc: via llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp On Fri, Jul

It was r274523. I’m not sure it was the same module. By mistake I restarted the build with the previous version without backing backing up the build artifacts :( Thanks, Taewook From: Teresa Johnson <tejohnson at google.com> Date: Friday, July 29, 2016 at 3:30 PM To: Taewook Oh <twoh at fb.com> Cc: via llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [ThinLTO]

Hi Daniel, Got it. If that's the case, can I implement it under the guidance of your insights/prototype? I think I can spend more time on implementation. Thanks, Taewook ________________________________ From: Daniel Berlin <dberlin at dberlin.org> Sent: Tuesday, April 4, 2017 9:41:30 PM To: Taewook Oh Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [NewGVN] Plan for GVNPRE? Of

There is a phi-node "%phi = phi i64 [%cast1, %if], [%cast2, %else]" in the common successor. The actual control flow is a bit more complex, but there is a common successor block, and %cast1 and %cast2 are the two values that the phi node in the common successor takes. Does the existence of the phi node affect optimization? Thanks, Taewook From: <mats.o.petersson at

It seems that the patch works for me as well, though the linker crashes with another error after that. Thanks! Mehdi, I couldn’t quite understand what do you mean by you don’t have a repro so you couldn’t upstream the patch. Aren’t .ll files you attached sufficient to submit along with the patch? If there is anything I can help you to upstream it, please let me know. -- Taewook On 7/22/16,

Hello Teresa, Thank you for your analysis. One thing to note is that the global materializer materializes the value as a function declaration, not a function definition. As I pasted on my first email, ; Materializable ; Function Attrs: nounwind uwtable define weak_odr void @foo(%1*) unnamed_addr #7 comdat($comdat1) align 2 personality i32 (...)* @__gxx_personality_v0 {} is materialized to ;

Ok, good to know. Any luck on a smaller test case for either of the problems? I tried building all the C/C++ SPEC cpu2006 benchmarks with -g -flto=thin at head and didn't get the failure. Let me try to look into how the debug metadata is normally dropped from the imported decl. In the meantime, could you find out the answers to the questions I had (see below) about the linkage type of the

Hi Daniel, Thank you for your detailed reply, and thank you for working on GVNPRE. I’d more than happy to test/evaluate it with our benchmark once it is ready. Please let me know if you need any help. Thanks, Taewook From: Daniel Berlin <dberlin at dberlin.org> Date: Tuesday, April 4, 2017 at 6:13 PM To: Taewook Oh <twoh at fb.com> Cc: "llvm-dev at lists.llvm.org"

On Fri, Jul 29, 2016 at 3:40 PM, Taewook Oh <twoh at fb.com> wrote: > It was r274523. I’m not sure it was the same module. By mistake I > restarted the build with the previous version without backing backing up > the build artifacts :( > So a couple things were added to gold since then, index-based linkonce/weak resolution and some more aggressive internalization. I don't

Thank you Easwaran for landing a great diff that enables the use of block frequency information in inliner. As of now, it seems that inliner can exploit the information only when profile data is available. However, instructions such as __builtin_expect may set branch weight metadata as well, which is useful for inliner. I think this problem can be addressed by letting llvm::getInlineCost function

Hello Teresa, Thank you for your reply. I’m trying to create a small repro but find it hard to nail down because originally it is a big build. This happens with gold linker. Thanks, Taewook From: Teresa Johnson <tejohnson at google.com> Date: Thursday, July 28, 2016 at 5:08 PM To: Taewook Oh <twoh at fb.com> Cc: via llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev]

Hello, I found that GVN doesn't promote identical sequence of instructions in if and else branch to their common predecessors. For example, for the following code snippet pred: … br i1 %cmp, label %if, label %else if: %incdec.ptr.1 = getelementptr inbounds i8, i8* %ptr, i64 1 %cast1 = ptrtoint i8* %incdec.ptr.1 to i64 … else: %incdec.ptr.2 = getelementptr inbounds i8, i8* %ptr,

Hello, I wonder if I can write a test that runs only on Linux. I was thinking of adding “REQUIRES” to the test, but couldn’t find a feature name for Linux (if one exists). Thanks! Best, Taewook -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170303/807b40ac/attachment-0001.html>