search for: flamedoge

...fy that with the current fix in SLM there is no need to wait for other issues to be fixed (minor issue). So you can move on with your patch. From: Agabaria, Mohammed Sent: Wednesday, June 07, 2017 15:24 To: Zaks, Ayal <ayal.zaks at intel.com>; Chandler Carruth <chandlerc at gmail.com>; Flamedoge <code.kchoi at gmail.com>; Dehao Chen <dehao at google.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] Enable vectorizer-maximize-bandwidth by default? Guys I have uploaded a fix on phabricator which fix the issue in SLM: https://reviews.llvm.org/D33983 Fr...

...ntributing these benchmarks to the LLVM test suite? > > > > > > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org > <llvm-dev-bounces at lists.llvm.org>] *On Behalf Of *Chandler Carruth via > llvm-dev > *Sent:* Tuesday, May 30, 2017 11:27 > *To:* Flamedoge <code.kchoi at gmail.com>; Dehao Chen <dehao at google.com> > *Cc:* llvm-dev <llvm-dev at lists.llvm.org> > *Subject:* Re: [llvm-dev] Enable vectorizer-maximize-bandwidth by default? > > > > If you care about such hardware, please run benchmarks with the flag? &g...

Hi Kevin, On April 11, 2017 at 4:14:14 PM, Flamedoge (code.kchoi at gmail.com) wrote: > So only "non-freed" malloc pointers are No-Alias which makes it > flow-sensitive. There is no reason why malloc couldn't return previously > freed location. Yes. Talking to Nick Lewycky on IRC, I figured out a shorter way of saying what I...

On Fri, May 19, 2017 at 4:01 PM Adam Nemet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I will run it on Cyclone/AArch64 next week. > FYI, we're still waiting on these Adam... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170530/7cb390ca/attachment.html>

...e of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can be used to manipulate the new object, if: ... a bunch of conditions". Which makes it even worse because they become aliasing again. On Tue, Apr 11, 2017 at 5:09 PM, Flamedoge via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I don't know when this was added on cppreference but > > > The behavior is undefined if after free() returns, an access is made > through the pointer ptr (unless another allocation function happened to > result in a po...

Even with -ffreestanding LLVM generates memcpy/memset? Does this mean some passes do not honor this flag? If you really wanted to prevent libcalls, you could technically translate those memcpy/memset to loops in lowering. Kevin On Sat, Oct 15, 2016 at 4:10 PM, Wolfgang McSneed via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Mehdi and Joerg, > > Thanks for your fast

Just for the interest of discussion, I find it completely weird and interesting that GCC needs to build itself 3 times to fully bootstrap. Has there been any interest in looking at a single compile build? I don't exactly know the limitations, but my naive thinking is that C++14 compiler source parsed by C++14 capable compiler and codegen'd to C99 (or older) source should make it compilable

Perhaps by "value" you mean points-to set? Either way, flow-sensitivity can only give you more precise -- but still not necessarily exact -- answers. Yours, Andrey === Compiler Architect NXP On Fri, Mar 10, 2017 at 6:39 PM, Flamedoge via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > For a given argument of a call instruction in the cfg: Where does the > value of the argument come from at the call site? > > GVN may tell you the values. I'm not sure why you would need flow > sensitive alias analys...

Thanks! That should get me on the right track. Direct reply was accidental. Thanks for putting me back on the list :-) I'll repost with details once I've got it working. On Mon, Feb 27, 2017 at 10:00 PM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi John, > > [Adding llvm-dev again; best to keep these things in the open so they > show up in future searches].

...ne in the codegen space to continue protecting these operations, but I was kind of hoping that the actual instruction selection would be reasonably safe. FWIW, FPToUI is not one of the parts my pending patch addresses. -Andy From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Flamedoge via llvm-dev Sent: Wednesday, April 19, 2017 10:14 AM To: Michael Clark <michaeljclark at mac.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [cfe-dev] FE_INEXACT being set for an exact conversion from float to unsigned long long > Are we better off using bran...

>I'd like to make LLD embed version information so that we can determine if an executable was created by LLD and if that's the case which version of LLD. >ld.bfd doesn't seem to embed any information, so we cannot tell whether an executable was linked by ld.bfd or not easily. >ld.gold embeds a string "GNU gold <version>" as ".note.gnu.gold-version"

Hi, I am looking for some flow-sensitive (context-insensitive) alias analysis algorithm implemented in LLVM. (I use LLVM 3.9, hope to switch to 4.0 soon.) As far as I know, none of the built-in analysis (basicAA, globals-modref, andersAA, etc.) is intended to be flow-sensitive. So I searched and came across these two 1. https://github.com/unsw-corg/SVF by Yulei Sui (for LLVM 3.8) 2.

On Mon, Oct 17, 2016 at 11:28 AM, Renato Golin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 17 October 2016 at 19:09, Flamedoge via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Just for the interest of discussion, I find it completely weird and > > interesting that GCC needs to build itself 3 times to fully bootstrap. > Has > > there been any interest in looking at a single compile build?...

Hello, I issued the following command to point the build to use clang and clang++, from a local llvm build directory included in PATH, instead of /usr/bin/{cc,c++}, cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm_src The configuration failed with the error stating the compiler didn't recognize '-std=c++11' flag, whereas clang compiled a dummy c++ file with

Hello, We’d like to keep track of which clang version was used to build our LLVM binaries. We use cmake and ninja with clang to build. What do you people think would be the cleanest way to know which version of clang is used, on a user’s machine, to build those binaries. I’m hoping to script this. I was thinking that getting cmake/ninja to spit out this information, if possible, would probably be

Hi Suman, I think you can ascertain pureness automatically leveraging the compiler instead of manually tagging attribute to each method and call-site. It would seem like impurity should be a transitive attribute. So this would conflict with below. __attribute__((annotate("pure"))) int add(uint32_t a, uint32_t b) { // impure by calling printf... ... printf("%d + %d =

...n FP status safe implementation of this might be faster in most cases. It’s at least worth taking some measurements to see if it is faster. -Andy From: Michael Clark [mailto:michaeljclark at mac.com] Sent: Thursday, April 20, 2017 4:02 PM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: Flamedoge <code.kchoi at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [cfe-dev] FE_INEXACT being set for an exact conversion from float to unsigned long long On 21 Apr 2017, at 8:50 AM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.c...

Hi everyone, I am currently testing out a combination of IR->IR passes with opt to benchmark how they affect performance. The source code works fine if simply use the clang (-O0/-O3) to directly compile to object files and link them. However, when I use opt with a select set of passes and then use llc to compile them to binary, the compiled binary is wrong. That makes me wonder if there are

Hi Daniel, On April 11, 2017 at 6:22:34 PM, Daniel Berlin (dberlin at dberlin.org) wrote: > Note: This is a generic problem with any situation where noalias exists but > the pointers are proven equal :) Yes. > TBAA, for example, has the same generic issue, we just drop the tbaa > metadata and declare it okay, even though it would have been UB at the > source level. Yes.  I

Hi all, I think I've spotted a semantic issue with marking @malloc and @realloc as noalias.  Say we have the program: int f() {   int* p0 = malloc(size of(int));   free(p0);   int* p1 = malloc(sizeof(int));   if (!p1) return 20;   int value = 0;   for (int i = 0; i < 1; i++) {     *p1 = 20;     value = *p1;     if (false)  // "false" is obscured in a way the compiler can't