similar to: [LLVMdev] [PATCH] Replacing EVT:s with MVT:s (when possible)

There seems to be quite a few places where the EVT type is used, but the code asserts if the variable/parameter is assigned something else than an MVT. Are there any general objections to replace EVT with MVT in these cases? For example, a quick look at TargetLowering.h give me this list of (member) functions, taking an EVT parameter, that asserts if the argument is not an MVT: getRegClassFor,

On Dec 3, 2012, at 1:14 PM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: > There seems to be quite a few places where the EVT type is used, but the code asserts if the variable/parameter is assigned something else than an MVT. Are there any general objections to replace EVT with MVT in these cases? > > For example, a quick look at TargetLowering.h give me this

On 29.11.2012, at 15:53, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: > Hi Chris and John, > > You are listed as administrators for llvm-commits. Can you provide some help in this issue: that my LLVM svn commit messages do not reach llvm-commits? My guess: the mailer may have issues with the non-ascii character "ä" in your name. See also

> I'm a bit confused by this concept. For the term byte, I use the "archaic" definition in the C (and C++) standard (section 3.6): addressable unit of data storage large enough to hold any member of the basic character set of the execution environment /Patrik Hägglund -----Original Message----- From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: den 19 oktober

> Please start a thread on llvmdev about this functionality, and outline what other intrinsics will have to change to add non-8-bit byte support. Well, memset is the only we have seen so far (our back-end is ~50% finished for an initial release). We have our own front-end as well (we are currently not using the clang front-end), and currently don't use many llvm intrinsics (only

Thanks, now it links. If nobody objects, I will commit the following patch: diff --git a/lib/Target/X86/X86JITInfo.cpp b/lib/Target/X86/X86JITInfo.cpp index 44d8cce..8acc220 100644 --- a/lib/Target/X86/X86JITInfo.cpp +++ b/lib/Target/X86/X86JITInfo.cpp @@ -339,6 +339,8 @@ extern "C" { /// must locate the start of the stub or call site and pass it into the JIT /// compiler function.

Success at r168899. Thanks! /Patrik Hägglund -----Original Message----- From: Chris Lattner [mailto:sabre at nondot.org] Sent: den 29 november 2012 17:13 To: Patrik Hägglund H Cc: criswell at illinois.edu; Benjamin Kramer; llvm-commits at cs.uiuc.edu; Tobias Grosser; LLVM Development List Subject: Re: [LLVMdev] Lost commit mails On Nov 29, 2012, at 7:11 AM, Benjamin Kramer <benny.kra at

Thanks! Our bug is now fixed. Our getMatchingSuperRegClass is huge (more than 300 lines), messy, and incomplete. > Or you could just rebase. On trunk, TableGen writes this difficult function for you. That in itself would be a compelling reason to get the rebase to trunk done. I just curious how large the generated version will be. :-) /Patrik Hägglund -----Original Message----- From: Jakob

On Nov 29, 2012, at 7:11 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > > On 29.11.2012, at 15:53, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: > >> Hi Chris and John, >> >> You are listed as administrators for llvm-commits. Can you provide some help in this issue: that my LLVM svn commit messages do not reach llvm-commits? >

On Oct 19, 2012, at 2:24 AM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: >> non-8-bit byte I'm a bit confused by this concept. I'm aware of the archaic meaning of the word byte, but it has meant 8 bits for the last 30 years. There's even an ISO/IEC standard. I know of architectures like Texas' C55x DSPs that address 16 bits at a time, but even their

On Oct 19, 2012, at 11:43 AM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: >> I'm a bit confused by this concept. > > For the term byte, I use the "archaic" definition in the C (and C++) standard (section 3.6): > > addressable unit of data storage large enough to hold any member of the basic character > set of the execution environment

On Fri, Oct 19, 2012 at 9:27 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Oct 19, 2012, at 2:24 AM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: > >>> non-8-bit byte > > I'm a bit confused by this concept. I'm aware of the archaic meaning of the word byte, but it has meant 8 bits for the last 30 years. There's even an

On Jan 19, 2012, at 2:16 AM, Patrik Hägglund <patrik.h.hagglund at ericsson.com> wrote: > Is it intended that in some cases it is necessary to use > "-disable-cross-class-join" to be sure the resulting code is ok? No. > I have several cases where cross class joins are carried out that makes > the code turn out illegal, because the "new" register class is

On Oct 19, 2012, at 10:47 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Oct 19, 2012 at 9:27 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> >> On Oct 19, 2012, at 2:24 AM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: >> >>>> non-8-bit byte >> >> I'm a bit confused by this concept.

Hi Chris and John, You are listed as administrators for llvm-commits. Can you provide some help in this issue: that my LLVM svn commit messages do not reach llvm-commits? /Patrik Hägglund -----Original Message----- From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Patrik Hägglund H Sent: den 28 november 2012 22:19 To: Tobias Grosser Cc:

2012/2/3 Patrik Hägglund <patrik.h.hagglund at ericsson.com>: > Hi, > > I've tracked the first problem (mentioned in my previous email, quoted > below) down further, ending up in the handling of alloca in > LoopRotation.cpp (from trunk): > >      // If the instruction's operands are invariant and it doesn't read > or write >      // memory, then it is

On Sat, Nov 10, 2012 at 3:21 AM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: > From r167602 and onwards I get a fail in 'make check-all' for llvm+clang, > built with gcc-4.7.1 (but not with clang-3.1) on Linux x86_64: > > Failing Tests (1): > Clang :: CodeGenCXX/mangle-ms-templates.cpp > > clang:

> @Patrik: would you mind to check if you are subscribed with your ericsson email address? As far as I can see, I'm subscribed to llvm-commits with the same email address used in commits (I get buildbot failure emails to the same mail account as llvm-commits messages). (BTW, why should my subscription status to llvm-commits matter?) > It would be nice to see your commit mails. Yes,

(+Chris, since I assume he wrote this policy - and, as I said in my previous email, I wouldn't mind seeing some justification or just seeing the rule go away & drop the anchors I added previously (or, if we're going to keep it, we could add more anchors & actually get to the point where we're -Wweak-vtable clean & enable that warning)) On Wed, Jun 12, 2013 at 1:44 PM,

Compiling LLVM with gcc, 4.3 and upwards, seems to give compile warnings. Is there any canonical gcc version that should be used (for building trunk)? >From http://llvm.org/docs/HowToReleaseLLVM.html#release-build: The builds of llvm, clang, and dragonegg must be free of errors and warnings in Debug, Release+Asserts, and Release builds. The table below specifies which compilers are used