similar to: [LLVMdev] LLVM IR in DAG form

On Sat, Feb 21, 2015 at 6:38 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > > > On 21 Feb 2015, at 05:59, Jeehoon Kang <jeehoon.kang at sf.snu.ac.kr> > wrote: > > > > this is Jeehoon Kang, a CS PhD student and a newbie to LLVM. > > > > I am wondering why LLVM IR's basic block consists of a list of > instructions, > >

I don't want to get into the debate w.r.t. which IR style is better - ask me over beer if you care about my opinions - but as an FYI, there are serious proposals being worked on to introduce some notion of memory def-use edges to help in analysing memory operations. I don't think we've settled on a concrete proposal yet, but I wouldn't be surprised to see something in the

Hi LLVMDev, this is Jeehoon Kang, a Ph.D. student of Software Foundations Laboratory ( http://sf.snu.ac.kr), Dept. of Computer Science & Engineering, Seoul National University. Our group studied the mem2reg pass, and we got a question on its algorithm. As far as I understand, the mem2reg pass essentially uses the SSA construction algorithm to promote allocas into registers, but there are

Dear llvm-dev, Hi! We're collecting mis-compilation bugs in gvn and mem2reg since 3.7.1. Specifically, We're interested in bugs in the following files: llvm/lib/Transforms/Scalar/GVN.cpp llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp We checked all reports in the LLVM bugzilla (https://bugs.llvm.org/), so I'd like to ask if you know any such a bug that is not reported in

On Tue, Apr 10, 2018 at 3:09 PM, Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Tue, Apr 10, 2018 at 10:28 AM, Friedman, Eli via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On 4/9/2018 8:19 PM, Jeehoon Kang via llvm-dev wrote: >> >> Dear llvm-dev, >> >> >> Hi! We're collecting mis-compilation

On Tue, Apr 10, 2018 at 10:28 AM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 4/9/2018 8:19 PM, Jeehoon Kang via llvm-dev wrote: > > Dear llvm-dev, > > > Hi! We're collecting mis-compilation bugs in gvn and mem2reg since > 3.7.1. Specifically, We're interested in bugs in the following files: > > llvm/lib/Transforms/Scalar/GVN.cpp

On 4/9/2018 8:19 PM, Jeehoon Kang via llvm-dev wrote: > Dear llvm-dev, > > > Hi! We're collecting mis-compilation bugs in gvn and mem2reg since > 3.7.1.  Specifically, We're interested in bugs in the following files: > > llvm/lib/Transforms/Scalar/GVN.cpp > llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp 3.7 was released over two years ago; there have been

I think it’s reasonable to expect that IR generated by frontends doesn’t do this. Not sure about transforms; I can imagine that we might speculate a load without proving all the bits are well-defined. -Eli From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Juneyoung Lee via llvm-dev Sent: Sunday, September 20, 2020 3:54 PM To: llvm-dev <llvm-dev at lists.llvm.org>

I think we need to allow this.  Otherwise, we have to prove that addresses are non-undef before we can hoist or sink a memory instruction.  Today, aliasing can use things like known bits, and if we imposed a no-undef in address requirement, we'd either need to replace such reasoning in AA, or have passes which wish to hoist/sink check the property afterwards. Or to say it differently, I

Thank you for the infos; it seems making it raise UB is problematic. Would clarifying it in LangRef be good? I can update the patch to contain the information instead. Another concern is then, how can we efficiently encode an assumption that a pointer variable in IR does not have undef bits? Certainly, in the front-end language, (most of) pointers won't have undef bits, and it would be great

Dear community, This is to brief you the progress of Interprocedural Register Allocation, for those who are interested to see the progress in terms of code please consider http://reviews.llvm.org/D20769 This patch contains simple infrastructure to propagate register usage information of callee to caller in call graph. The code generation order is changed to follow bottom up order on call graph ,

Dear expeRts, I would simplify following code. --------------------------------------------- youtput <- function(x1, x2){ n <- length(x1) y <- vector(mode="numeric", length=n) for(i in 1:n){ if(x1[i] >=5 & x1[i] <= 10 & x2[i] >=5 & x2[i] <=10) y[i] <- 0.631 * x1[i]^0.55 * x2[i]^0.65 if(x1[i] >=10 & x1[i] <= 15 &

Ok, makes sense. My suggestion is that we patch the IR Verifier to ensure that the mask is indeed a vector of constants and/or undefs. Right now it only runs the standard checks for instructions. We will also run Alive2 on the test suite to make sure undef is never replaced in practice. Thanks, Nuno -----Original Message----- From: Eli Friedman <efriedma at quicinc.com> Sent: 27 de

Dear Community, The patch for Interprocedural Register Allocation has been committed now , thanks to Mehdi Amini for that. We would like you to play with it and let us know your views and more importantly ideas to improve it. The test-suite run has indicated some non trivial issue that results in run time failure of the programs, we will be investigating it more. Here are some stats :

> > Okay, it's just not immediately undefined behaviour. The C model has more > issues because of the problem with how "trap representation" is defined > (which precludes trap representations for unsigned char, two's complement > signed char, etc.). This interpretation is further stressed because C only explicitly ascribes > undefined behaviour to trap

> I almost change all the instruction formats. It was a huge work. I am going > to compile and run it now. We have done the similar work[1] on this topic by gcc and we have start migrate our platform to LLVM. In my experience, you need to take care the follow part: * ARMBaseRegisterInfo::getRegPressureLimit * ARMBaseRegisterInfo::getRawAllocationOrder * CalleeSavedRegs *

Dear expeRt, I would like to know whether a function similar to str_replace() in php exists in R. Looking forward to hearing from you. Best, ========================================================= Center of Excellence for Science and Innovation Studies, Royal Institute of Technology Drottning Kristinas v?g 30 100 44 Stockholm, Sweden e-mail: donghoh at infra.kth.se, doriaba2 at

On Wed, Jun 15, 2016 at 6:16 AM, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Vivek, > > How much of the slow down on runtime comes from the different layout of > the function in the asm file? (I.e., because of the dummy scc pass.) > > Hello Quentin, Please do not consider previous results as there was a major bug in RegMask calculation due to not considering

> > // Members are initialized to poison at object creation. >> p = alloca {i8, i32} // p[0], p[4~7] are poison >> p[0] is an i8, so it shouldn't be poison? > > My interpretation of standard is that reading uninitialized char can also yield trap representation. If uninitialized, char variable has indeterminate value, and C/C++ does not seem to forbid reading trap

[wincent at PC-BSD]export MAKE=gmake [wincent at PC-BSD]sudo R ..... > install.packages("Matrix") --- Please select a CRAN mirror for use in this session --- Loading Tcl/Tk interface ... done trying URL 'http://bibs.snu.ac.kr/R/src/contrib/Matrix_0.999375-9.tar.gz' Content type 'application/x-gzip' length 1483674 bytes (1.4 Mb) opened URL