similar to: [LLVMdev] Compiler error: LoopStrengthReduce.cpp

On Tue, May 12, 2009 at 5:01 PM, Dale Johannesen <dalej at apple.com> wrote: > > On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: > >> The error given: >> >> ..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) : >> error C2668: 'abs' : ambiguous call to overloaded function >> >> It should be rather obvious from the

On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: > The error given: > > ..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) : > error C2668: 'abs' : ambiguous call to overloaded function > > It should be rather obvious from the message. The error is in > LoopStrengthReduce.cpp on line 1016: > (unsigned(abs(SInt)) < SSInt || (SInt %

On May 12, 2009, at 5:01 PMPDT, OvermindDL1 wrote: > On Tue, May 12, 2009 at 5:01 PM, Dale Johannesen <dalej at apple.com> > wrote: >> >> On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: >> >>> The error given: >>> >>> ..\..\..\..\trunk\lib\Transforms\Scalar >>> \LoopStrengthReduce.cpp(1016) : >>> error C2668:

On Tue, May 12, 2009 at 6:26 PM, Dale Johannesen <dalej at apple.com> wrote: > > On May 12, 2009, at 5:01 PMPDT, OvermindDL1 wrote: > >> On Tue, May 12, 2009 at 5:01 PM, Dale Johannesen <dalej at apple.com> >> wrote: >>> >>> On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: >>> >>>> The error given: >>>>

On May 12, 2009, at 10:59 PMPDT, OvermindDL1 wrote: >>>>> The error given: >>>>> >>>>> ..\..\..\..\trunk\lib\Transforms\Scalar >>>>> \LoopStrengthReduce.cpp(1016) : >>>>> error C2668: 'abs' : ambiguous call to overloaded function >>>>> >> I checked in a fix. > > Also, IndVarSimplify.cpp

Hey, Downloaded the release, used CMake to create solution... building mostly seems to be OK, except for a couple of compiler errors. warning C4090: 'function' : different 'const' qualifiers d:\companyone\external\llvm\source\llvm-2.7\lib\support\regengine.inc 188 error C2248: 'llvm::EquivalenceClasses<ElemTy>::ECValue::ECValue' : cannot access private member

Hi Jonas, Are you talking specifically about the induction variable? You might look at what I did for PowerPC's counter-based loops (lib/Target/PowerPC/PPCCTRLoops.cpp, etc.). -Hal ----- Original Message ----- > From: "Jonas Paulsson via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, March 28,

Hello, This patch aims to improve compile time performance by increasing the SCEV vector size in LoopStrengthReduce. It is observed that the BaseRegs vector size is 4 in most cases, and elements are frequently copied when it is initialized as SmallVector<const SCEV *, 2> BaseRegs. Our benchmark results show that the compilation time performance improved by ~0.5%. Patch by Wan Xiaofei.

This is related to an issue in loop strength reduction [1] that I've been trying to fix on and off for a while. [1] has a more detailed description of the issue and an example, but briefly put, I want LSR to consider formulae that have "Zext T" as base and/or scale registers, and to appropriately rate such formulae. My first attempt[2] at fixing this was buggy and had to be

Hey, So I tried to fix these errors, and have everything compiling now... not too difficult, just annoying. error C2248: 'llvm::EquivalenceClasses< > > ElemTy>::ECValue::ECValue' : cannot access private member declared in class > 'llvm::EquivalenceClasses<ElemTy>::ECValue' C:\Program Files > (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory 208

Hi, I am looking for a way to rewrite induction variables to use an addition of -1 whenever possible (and not otherwise unprofitable). This is needed to utilize hardware loop instructions, which are present on SystemZ (branch on count). Later in the backend, an 'add -1; compare w/ 0; jne 0'-sequence can be replaced with a brct instruction. I could not find any way in the LSR pass to

Hi Hal, yes, it's all about the induction variable. SystemZ has a late pass (pre-emit) that looks for MI sequences that can be rewritten to 'branch on count'. Currently only about half the number of BRCTs are output compared to gcc on the same benchmarks. One reason for this is that when a loop gets unrolled, the loop gets a greater increment / decrement than 1, which makes the

Dear R-devel, I am trying to alter rpart so that it makes additional calculations when growing the tree. In the "rpart.s" there is a call to the C routine: rp <- .C("s_to_rp2", as.integer(nobs), as.integer(nsplit), as.integer(nodes), as.integer(ncat),

Sriram, This patch looks good. Please commit. ...and thanks for the data. -Andy On Jan 29, 2013, at 12:59 PM, "Murali, Sriram" <sriram.murali at intel.com> wrote: > Hello, > This patch aims to improve compile time performance by increasing the SCEV vector size in LoopStrengthReduce. It is observed that the BaseRegs vector size is 4 in most cases, and elements are

The attached patch gets rid of the "error C2668" mentioned on the wiki page (all the other errors seem to be fixed in SVN already AFAICT): http://wiki.llvm.org/How_do_I_compile_on_Visual_C%2B%2B%3F Applying this to trunk fixes http://llvm.org/bugs/show_bug.cgi?id=5592 for me. -------------- next part -------------- A non-text attachment was scrubbed... Name:

Does not seem to be a straight error with LLVM itself, but rather the tools, linking issues, here are the errors: Opt: 30> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.exp 30>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall

Dear All, I am using fexact.c on a C++ program I wrote. To minimize dependencies on other files (e.g., to not need to include R.h and ctest.h ---now I only include the R files Boolean.h, Constants.h, and Memory.h), I have re-written all declarations of Sints as ints and, what is potentially more serious, I have re-written the line (lines 329 and 330, in fexact.c on R-1.6.1) /* IMAX is the

Christian, the question for you is towards the end... On 09/10/2015 15:39, Denis V. Lunev wrote: > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c > index 62cf8c9..15c3c02 100644 > --- a/arch/x86/kvm/hyperv.c > +++ b/arch/x86/kvm/hyperv.c > @@ -23,13 +23,265 @@ > > #include "x86.h" > #include "lapic.h" > +#include "ioapic.h"

Christian, the question for you is towards the end... On 09/10/2015 15:39, Denis V. Lunev wrote: > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c > index 62cf8c9..15c3c02 100644 > --- a/arch/x86/kvm/hyperv.c > +++ b/arch/x86/kvm/hyperv.c > @@ -23,13 +23,265 @@ > > #include "x86.h" > #include "lapic.h" > +#include "ioapic.h"

> On that note, I think that in general it would be useful to have some > target-independent (CodeGen) pass that would do the majority of the > work for hardware loop generation. I have thought about it, but I > won't be able to do anything in the short term. > > -Krzysztof > I think a first and useful step would be to let targets optionally have the loop induction