similar to: [LLVMdev] Canonical compilers for building LLVM?

> 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

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

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:

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

> 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

Hi, Is it intended that in some cases it is necessary to use "-disable-cross-class-join" to be sure the resulting code is ok? I have several cases where cross class joins are carried out that makes the code turn out illegal, because the "new" register class is not allowed in all instructions where it is now used. For example, by joining %vreg4, %vreg7 and %vreg9 the

On 11/28/2012 03:47 PM, Jean-Daniel Dupas wrote: > > Le 28 nov. 2012 à 15:07, Tobias Grosser <tobias at grosser.es> a écrit : > >> Hi, >> >> I just realized non of Patrik's commit mails has every reached llvm-commits. Neither my own archive nor the web interface contains commit messages for any of his commits. The relevant commits are >> >> 168785,

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

> 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

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

Hi Quentin, Jonas looked further into the problem below, and asked me to submit his patch. Note the we have our own out-of-tree target, and we have not been able to reproduce this problem on an in-tree target. /Patrik Hägglund [MachineSinking] Conservatively clear kill flags after coalescing. This solves the problem of having a kill flag inside a loop with a definition of the register prior to

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

I tried to build LLVM with 'gcc-4.8.1 -flto', and when linking unittest programs, I got the following error: /tmp/cc8pMk84.ltrans30.ltrans.o:(.data.rel.ro._ZTIN4llvm2cl15OptionValueCopyISsEE[_ZTIN4llvm2cl15OptionValueCopyISsEE]+0x10): undefined reference to `typeinfo for llvm::cl::GenericOptionValue'

Hi, I would like to force the minimum number of bits allocated for a variable in memory to be 16. From what I have seen, i1 is already represented on 8 bits. So, the only change would be to represent i1 and i8 on 16 bits, as all other types already fulfill this condition. TargetData can help by setting a higher alignment, thus although the type is i1 or i8, the number of allocated bits is 16.

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

Hi Alexandra, I'm not sure want you want to do. Is the data layout string (http://llvm.org/docs/LangRef.html#datalayout, also usually set by each target specific *TargetMachine constructor), for setting the alignment good enough for you? Or is it more than the alignment you want to control? Do you have a target with 16-bit bytes? In that case, there is quite a lot of changes that needs to be

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 Sep 5, 2014, at 10:21 AM, Juergen Ributzka <juergen at apple.com> wrote: > clearKillFlags seems a little "overkill" to me. In this case you could just simply transfer the value of the kill flag from the SrcReg to the DstReg. We are extending the live-range of SrcReg. I do not see how you could relate that to the kill flag of DstReg. Therefore, I still think, this is the