similar to: Confused about optimization pass order

It's not about the pointer per se but the object it points to. If we have 2 objects of which we know the minimal/maximal size respectively we can sometimes conclude the objects must be different. Accesses to different objects do not alias. We already use that logic but we don't have the upper bound size as an attribute. Hence, it only applies if we know the exact size, basically is we see

On 01/28, Karl Rehm wrote: > > > > I need to take a closer look but I would have expected BasicAA to be > > able to determine that `do_log` and `R` cannot alias. In the -Os version > > (lower right here https://gcc.godbolt.org/z/KLaeiH), the write to `R` > > clobbers the read from `do_log` which prevents us from removing the > > load/store pair. My reasoning

Hey everyone, I was looking into how the global optimization pass fares against things like what's reported in https://bugs.llvm.org/show_bug.cgi?id=44676 Looking at this, I think it would be pretty trivial to optimize that down given that there are already threading assumptions made: https://godbolt.org/z/u6ZqoB Is this something I can look into? Another thing is that currently *all* external

Hi Karl, Roman, On 01/28, Roman Lebedev via llvm-dev wrote: > On Tue, Jan 28, 2020 at 8:09 PM Karl Rehm via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I was looking into how the global optimization pass fares against > > things like what's reported in > > https://bugs.llvm.org/show_bug.cgi?id=44676 I need to take a closer look but I would have expected

I am not convinced this is a jump-threading issue, but in the domain of ScalarEvolution. ScEv would need to find out which of the exits are taken or whether it loops infinitely. One can see that it exits after 10000 iterations, but ScalarEvolution cannot tell: https://godbolt.org/z/dCqdvv Michael Am Mo., 3. Feb. 2020 um 11:56 Uhr schrieb Karl Rehm <klrehm123 at gmail.com>: > > Well

How does the code you would like to have look like? I don't see a relevant difference compared to gcc: https://godbolt.org/z/F-oah4 (clang unnecessarily introduces another temporary register, but that seems unrelated) Michael Am So., 2. Feb. 2020 um 18:24 Uhr schrieb Karl Rehm via llvm-dev <llvm-dev at lists.llvm.org>: > > Here's a better example. https://godbolt.org/z/fpTyFS

Within the LLVM pass manager infrastructure, suppose we have two transformation passes, pass A makes some improvements, then pass B does likewise, but this creates opportunities for pass A to create further improvements (e.g. suppose B was function inlining) so it's desirable to run A again. How does the LLVM pass manager currently deal with this? -------------- next part -------------- An

Holy crap, I completely missed that. I'm sorry! That's my fault. On Sun, Feb 2, 2020 at 12:15 PM Johannes Doerfert <jdoerfert at anl.gov> wrote: > On 01/30, Karl Rehm via llvm-dev wrote: > > Since the bug report here: https://bugs.llvm.org/show_bug.cgi?id=44679 > I've > > been thinking about cases like it, such as: https://godbolt.org/z/Fwq8mn > > >

Interesting, so I guess we can check for whether it's an array type and adjust accordingly instead? Blocking *all* global variables without definitive initializers feels a bit much to me, especially if they have primitive types (i.e. integers) that don't have the potential to be screwed around with like this. On Wed, Jan 29, 2020 at 8:14 PM George Burgess IV < george.burgess.iv at

Hi, First of all, I would like to introduce myself as I will probably have many questions over the next few weeks and want to thank you guys in advance for your help. I'm a cancer researcher and I need to learn R to complete a few projects. I have an introductory background in Python. My questions at the moment are based on the following sample input file: *Sample_Input_File*

Hi-- I have three columns in an input file: MONTH QUARTER YEAR 2012-07 2012-3 2012 2001-07 2001-3 2001 2002-01 2002-1 2002 I want to make output like so: MONTH QUARTER YEAR 07 3 2012 07 3 2001 01 1 2002 I was having some trouble getting the regular expression to work. I think it should

Since the bug report here: https://bugs.llvm.org/show_bug.cgi?id=44679 I've been thinking about cases like it, such as: https://godbolt.org/z/Fwq8mn I wonder what we can do about this in a general sense. As far as I can tell, the jump threading algorithm is *really* conservative, which is one reason this isn't working as well as I'd hope; however, we don't want to produce

On Thu, Jun 4, 2015 at 3:58 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > Personally, I think the right approach is to add a bool to > createGlobalDCEPass defaulting to true named something like > IsAfterInlining. In most standard pass pipelines, GlobalDCE runs after > inlining for obvious reasons, so the default makes sense. The special case > is

Hm. I assumed that JumpThreading would be the primary factor in optimizing code like this. Guess not. I'll need to look into SimplifyCFG to see what prevents it from doing the same thing to the other loop: https://godbolt.org/z/F6NjdG On Mon, Feb 3, 2020 at 3:09 PM Michael Kruse <llvmdev at meinersbur.de> wrote: > I assumed the LLVM-IR behind the godbolt link represented the C code

Hi, My project is set up the following way: root directory contains the following folders: folders: "Breast_Cancer" AND "Colorectal_Cancer" AND "Lung_Cancer" AND "Prostate_Cancer" I want to create a file, call it: "repeating_functions.R" and place it in the root directory such that I can call these functions from within the sub-folders in each

I've been implementing ELF/AArch64 support for lld. I can now successfully link and run a simple "Hello World" app for both dynamic and static linking. I'd like to upstream this implementation, but wanted to get feedback on how people might like to see it. Would people rather see the whole thing in one shot, each file individually or somehow break it down even farther? The

Hi, I'm trying to build a Forest Plot using the second and fourth columns in the table (test.csv) below. My code is the following: curated <- data.frame("test.csv") tmp <- curated$coef tmp1 <- curated$se_coef plt <- metaplot(tmp, tmp1, xlim = c(-.45, .45)) I keep getting the following error at the last line and am not sure why: Error in if (is.na(lower[i] + upper[i]))

Hey, I just googled my error and many things came up. I followed the leads and read the ?read.delim page; I tried changing header = TRUE, and row.names = TRUE-- but I've still been having trouble fixing it, so I would greatly appreciate any help you can provide. Here is my code: rm(list=ls()) source("../../functions.R") uncurated <-

On Wed, Oct 9, 2019 at 8:12 AM David Greene <dag at cray.com> wrote: > Mehdi AMINI via cfe-dev <cfe-dev at lists.llvm.org> writes: > > >> I have a bit of concern about this sort of thing - worrying it'll lead > to > >> people being less cautious about writing the more isolated tests. > >> > > > > I have the same concern. I really

In this function (used to check the size of a global) there is an initial check for whether the initializer to this function is "definitive." My question is: why do we need this? How does the object's size change if a global's initializer is defined at link time? Thanks, Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: