similar to: [LLVMdev] how to mark tests as XFAIL and prefix?

On Mon, Oct 6, 2008 at 9:03 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I am attempting to get indexing code generation working with my backend. > However, it seems that the addresses being calculated is being multiplied by > the width of the data type. That's how most normal architectures/address spaces work. Is there something unusual about address space 11 in

-----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Monday, October 06, 2008 4:41 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Address calculation On Mon, Oct 6, 2008 at 9:03 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I am attempting to get indexing code generation working with

Maybe it would be easier to provide a bitcode example of this problem. After thinking about this more, I'm not sure if this is applicable to SPIR itself. For you to have a constant GEP expression, you have to know the pointer size in order to correctly generate the expression. Since the pointer size itself is not known, I don't yet see how you can generate a constant expression that is

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Nadav Rotem > Sent: Wednesday, September 12, 2012 2:05 PM > To: Ouriel, Boaz > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] SPIR Portability Discussion > > > > > > ****Pointers**** > > During

On Jul 22, 2010, at 2:44 PMPDT, Patrick Alexander Simmons wrote: > From http://llvm.org/docs/TestingGuide.html > > Some tests are known to fail. Some are bugs that we have not fixed > yet; > others are features that we haven't added yet (or may never add). In > DejaGNU, the result for such tests will be XFAIL (eXpected FAILure). > In > this way, you can tell the

From http://llvm.org/docs/TestingGuide.html Some tests are known to fail. Some are bugs that we have not fixed yet; others are features that we haven't added yet (or may never add). In DejaGNU, the result for such tests will be XFAIL (eXpected FAILure). In this way, you can tell the difference between an expected and unexpected failure. The tests in the test suite have no such feature at

Thanks, Dale, that really helps. What about disabling only one backend of a specific test? Thanks, --Patrick On 07/22/10 16:04, Dale Johannesen wrote: > > On Jul 22, 2010, at 2:44 PMPDT, Patrick Alexander Simmons wrote: > >> From http://llvm.org/docs/TestingGuide.html >> >> Some tests are known to fail. Some are bugs that we have not fixed yet; >> others are

Micah, You're saying it works for you, but Clang doesn't currently anywhere near the range of horrible constantexpr constructs it is possible to create. You can "get by" at the moment with just handling ConstantGEPs, because of the way Clang works. But SPIR isn't restricted to Clang, and the problem is that it is *possible* (although not probable, or nice, but that is

It is my view that this is an implementation detail and not an issue with the SPIR spec. As SPIR is just a representation of a program in a portable manner, it is up to the consumer of SPIR to correctly set up the kernels based on the devices calling convention/ABI when the SPIR binary is loaded for that specific device. From: mankeyrabbit at gmail.com [mailto:mankeyrabbit at gmail.com] On

On Jul 25, 2010, at 2:37 AMPDT, Patrick Simmons wrote: > Thanks, Dale, that really helps. > > What about disabling only one backend of a specific test? > > Thanks, > --Patrick Not sure I understand, the test for Sparc in the example Makefile would appear to do that. You'll need to figure out a way to test for whatever condition you want to look at. There are lots of

I'm sorry; I should have been more clear. I mean, for instance, run a test but only with, say, llc, not with lli or cbackend. Thanks, --Patrick Dale Johannesen wrote: > > On Jul 25, 2010, at 2:37 AMPDT, Patrick Simmons wrote: > >> Thanks, Dale, that really helps. >> >> What about disabling only one backend of a specific test? >> >> Thanks, >>

From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of Richard Smith Sent: Wednesday, September 12, 2012 2:51 PM To: Villmow, Micah Cc: Ouriel, Boaz; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] SPIR Portability Discussion On Wed, Sep 12, 2012 at 2:23 PM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote: From:

Hi, Currently, no tests that use lli without "-force-interpreter" are expected to pass when executing on an AArch64 model. However, they will pass if built and run on (say) X86, just setting the default target triple. So XFAIL gets unexpected passes on a compiler merely targetting AArch64 and leaving the tests as they are gives unexpected failures when they're run on a model. Does

Hi, I am currently trying to set up new performance and regression testers for Polly and LLVM and would like to XFAIL two test cases. I am using the LNTBuilder instead of the NightlyTestBuilder out of the assumption that the LNTBuilder is the more modern solution. However, when trying to xfail test cases I realized the xfail=[] parameter of getLNTFactor is ignored. Previously this was not an

Yes, it would. But I was concerned Micah was just going to write it off as an implementation detail, so I felt that I should offer a "less correct but less work" option for him to consider. Cheers, James On 29 September 2012 03:16, Owen Anderson <resistor at mac.com> wrote: > > On Sep 28, 2012, at 9:45 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > >

After more digging, it seems that the SIGN_EXTEND_INREG is getting generated in DAGCombiner.cpp:3033. // fold (sext (truncate x)) -> (sextinreg x). if (!LegalOperations || TLI.isOperationLegal(ISD::SIGN_EXTEND_INREG, N0.getValueType())) { if (Op.getValueType().bitsLT(VT)) Op = DAG.getNode(ISD::ANY_EXTEND, N0.getDebugLoc(), VT,

On Wed, Sep 12, 2012 at 2:23 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > ** ** > > ** ** > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Richard Smith > *Sent:* Wednesday, September 12, 2012 1:55 PM > *To:* Ouriel, Boaz > *Cc:* cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > *Subject:* Re:

Right, it's failing when it tries to materialize a move of a constant into a register. But it's only trying to do that because it previously failed to fold the constant into the AND. What you need to do is step through the path it takes when matching the AND node, and try to figure out why it ends up selecting the register-register version rather than the register-immediate version.

Hi all, I'm investigating the following test case that reports as an unexpected pass on powerpc64-unknown-linux-gnu. Clang : CodeGenCXX/member-alignment.cpp This test case is marked as XFAIL for arm and powerpc. However, the test passes fine for powerpc64-unknown-linux-gnu. There are two tests of this form: void t::bar(void) { // CHECK: _ZN1t3barEv{{.*}} align 2

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Richard Smith Sent: Wednesday, September 12, 2012 1:55 PM To: Ouriel, Boaz Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] SPIR Portability Discussion On Wed, Sep 12, 2012 at 12:27 PM, Ouriel, Boaz <boaz.ouriel at intel.com<mailto:boaz.ouriel at intel.com>> wrote: Hey