similar to: [LLVMdev] cygwin build patch

On Jan 19, 2009, at 7:44 AM, Jay Foad wrote: > LLVM doesn't build out of the box on Cygwin, because Cygwin defines > uint32_t as "unsigned long" rather than "unsigned int". > > The attached patch allows me to build head of svn (rev 62510) on > Cygwin using GCC 4. Can this be committed please? Thanks applied:

>> I realise that the DataTypes.h.in part might be controversial. Also, >> there's probably a better place to put it, but I'm not sure where. > > I didn't apply this part. What problems does it cause to not have > this? Can we fix uses of max and min? I get these errors in lib: .../lib/Analysis/ValueTracking.cpp:162: error: no matching function for call to

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

>> In this function, the `this` pointer is not pointing at an Operator >> object. That's undefined behavior, right? > > Yes. Well then I guess the next step is how to fix it. Maybe someone with a bit more experience with the Operator code and how it is used could make a suggestion? (I just stumbled upon this code yesterday while doing some refactoring, so I'm not

Hi, I'd like to make code emitted by LLVM that includes floating point operations which raise FP exceptions behave closer to what is defined by IEEE754 standard. I'm not going to "fix everything", just incorrect behaviour I faced so far. Most of troubles regarding FP exceptions are caused by optimizations, so there should be a flag to disable/block them if one wants to get

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Sean Silva > Subject: Re: [LLVMdev] Undefined behavior in Operator class? > > > In this function, the `this` pointer is not pointing at an Operator > > > object. That's undefined behavior, right? > > Yes. > Well then I guess the next step is how to fix it. I tried

On 03/17/2017 04:30 PM, Mehdi Amini via llvm-dev wrote: > >> On Mar 17, 2017, at 11:50 AM, Mikhail Zolotukhin via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> >> One of the most time-consuming passes in LLVM middle-end is >> InstCombine (see e.g. [1]). It is a very powerful pass capable

> On Mar 17, 2017, at 6:12 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > Honestly, I'm not a huge fan of this change as-is. The set of transforms that were added behind ExpensiveChecks seems awfully strange and many would not lead the reader to believe that they are expensive at all (the SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls being the

As the title suggests, what is the status of compiling llvm on versions of MSVC less than 2012? Not so much "Does it work?", but more like "Should any thought be given to whether or not something will break it?" Right now there are a bunch of warnings when compiling LLDB on Windows because it uses various symbols which have been defined since VS2012, but which are re-defined

> On Mar 17, 2017, at 6:12 PM, David Majnemer via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Honestly, I'm not a huge fan of this change as-is. The set of transforms that were added behind ExpensiveChecks seems awfully strange and many would not lead the reader to believe that they are expensive at all (the SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls

On Jan 20, 2009, at 1:22 AM, Jay Foad wrote: >>> I realise that the DataTypes.h.in part might be controversial. Also, >>> there's probably a better place to put it, but I'm not sure where. >> >> I didn't apply this part. What problems does it cause to not have >> this? Can we fix uses of max and min? > > I could try to fix this by changing

> To (hopefully) make it easier to answer this question, I've posted my (work-in-progress) patch which adds a known-bits cache to InstCombine. > I rebased it yesterday, so it should be fairly easy to apply: https://reviews.llvm.org/D31239 - Seeing what this does to the performance of the > benchmarks mentioned in this thread (among others) would certainly be interesting. Thanks! I

> I'd prefer to avoid uint32_t. I committed a couple patches, can you > try again and let me know if you see any other failures? With the attached patch I can build successfully on Cygwin. The APInt.cpp part of the patch is just s/uint32_t/unsigned/g. Thanks, Jay. -------------- next part -------------- A non-text attachment was scrubbed... Name: cygwin.patch Type:

Hi, Great to see someone working on this. This will benefit the performance portability goal of the pocl's OpenCL kernel compiler. It has been one of the low hanging fruits in improving its implicit WG vectorization applicability. The use case there is that sometimes it makes sense to devectorize the explicitly used vector datatype code of OpenCL kernels in order to make better opportunities

Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> writes: > E.g., the last time I checked, the inner loop vectorizer (which pocl exploits) > just refused to vectorize loops with vector instructions. It might not > be so drastic with the SLP or the BB vectorizer, but in general, it might > make sense to let the vectorizer to do the decisions on how to map the > parallel

Chandler Carruth wrote: > This seems fine to me, but I'd like to make sure it looks OK to Nick as > well. I strongly prefer baking in knowledge about the intrinsics themselves into the passes if possible. Metadata will always be secondary. Separately, should value tracking look use range metadata when it's available? Absolutely. I think it should apply to all CallInst not just

Hi, The range metadata can only be attached to LoadInst for now. I am considering extending its usage to IntrinsicInst so that the frontend can annotate the range of the return value of an intrinsic call. e.g., %a = call i32 @llvm.xxx(), !range !0 !0 = metadata !{ i32 0, i23 1024 } The motivation behind this extension is some optimizations we are working on for CUDA programs. Some special

Hello, I'm starting to play with LLVM today and I've trouble compiling it. I'm working under Windows Vista, with the gcc from Cygwin: gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) Is LLVM supposed to work with this version of GCC (probably using the -mno-cygwin option to get a Mingw-like behavior)? The LLVM source tree is from the current SVN trunk. Compilation

On 17 June 2014 06:41, Eli Bendersky <eliben at google.com> wrote: > On Tue, Jun 17, 2014 at 1:38 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > >> Chandler Carruth wrote: >> >>> This seems fine to me, but I'd like to make sure it looks OK to Nick as >>> well. >>> >> >> I strongly prefer baking in knowledge about the

Some optimizations depend on whether alloca instruction always has non-zero value. Currently, this checking is done by isKnownNonZero() in ValueTracking, and it assumes alloca in address space 0 always has non-zero value but alloca in non-zero address spaces does not always have non-zero value. However, this assumption is incorrect for certain targets. For example, amdgcn---amdgiz target has