similar to: [LLVMdev] get Type of SDValue?

Hello Patrik, > And as an example, in the XYZTargetLowering::lowerCall method for my target, is there any way for me to get what Type the SDValue Callee really corrensponds to? Why do you need this information there? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

> 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

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:

> 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

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 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

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.

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? >

> @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,

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

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 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 Wednesday 04 Apr 2012 12:41:49 Patrik Hägglund H wrote: > Hi Tim, > > > So I've come to the conclusion that the real flaw is LLVM > > not exposing enough information to the target-dependent > > backend code for it to do the right thing. > > We also had this problem. You might find this patch useful as a starting > point:

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

I tried to compile LLVM with gcc-4.8.1 -flto. I got the following error, when linking lli, llc, opt, or libLTO.so: `LLVMX86CompilationCallback2' referenced in section `.text' of /tmp/cclv7BYB.ltrans0.ltrans.o: defined in discarded section `.text' of X86JITInfo.o (symbol from plugin) collect2: error: ld returned 1 exit status Removing the LLVM_LIBRARY_VISIBILITY attribute for

> It's definitely doable, but I'd be worried about the maintenance burden. Yes, that is a problem. We are currently not allowed to reveal our target (which has 16-bit bytes, and registers with non-power-of-two bit widths) fully, and therefore not able to submit it upstream. One idea we have toyed with is to create a simple "dummy" version of our target, just to be able

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

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

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:

Hi Patrik, > DAG.getMachineFunction().getFunction() only works in LowerFormalArguments (there it returns the callee), not in LowerCall (where it returns the caller, rather than the callee). You need to pass more information about the function type to LowerCall (besides partial information such as the isVarArg parameter). > > I can provide a patch if you are interested. (Unfortunately,