Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] [cfe-commits] [PATCH] [llvm+clang] memset for non-8-bit bytes"
2012 Oct 19
0
[LLVMdev] [llvm-commits] [cfe-commits] [PATCH] [llvm+clang] memset for non-8-bit bytes
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
2012 Oct 19
2
[LLVMdev] [llvm-commits] [cfe-commits] [PATCH] [llvm+clang] memset for non-8-bit bytes
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
2012 Oct 19
0
[LLVMdev] [llvm-commits] [cfe-commits] [PATCH] [llvm+clang] memset for non-8-bit bytes
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.
2012 Oct 19
4
[LLVMdev] [llvm-commits] [cfe-commits] [PATCH] [llvm+clang] memset for non-8-bit bytes
> 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
2012 Oct 19
0
[LLVMdev] [llvm-commits] [cfe-commits] [PATCH] [llvm+clang] memset for non-8-bit bytes
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
2012 Nov 29
2
[LLVMdev] Lost commit mails
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 Nov 28
0
[LLVMdev] Lost commit mails
> @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,
2012 Nov 29
2
[LLVMdev] Lost commit mails
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?
>
2012 Nov 29
0
[LLVMdev] Lost commit mails
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
2012 Jan 19
0
[LLVMdev] Problem with cross class joins in the RegisterCoalescer
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
2013 Jun 12
2
[LLVMdev] [PATCH] gcc-4.8.1 -flto, error for visibility of LLVMX86CompilationCallback2?
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.
2012 Jun 08
1
[LLVMdev] Canonical compilers for building LLVM?
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
2013 Jun 10
1
[LLVMdev] gcc-4.8.1 -flto, error for visibility of LLVMX86CompilationCallback2?
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
2012 Feb 03
1
[LLVMdev] Issues with the llvm.stackrestore intrinsic - now LoopRotation handling of alloca
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
2015 Mar 11
3
[LLVMdev] n-bit bytes for clang/llvm
> 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 Nov 12
0
[LLVMdev] Need help reading the LLVM Buildbot results
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:
2012 Nov 22
0
[LLVMdev] Set the minimum number of allocated bits for a variable
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
2012 Nov 28
3
[LLVMdev] Lost commit mails
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,
2012 Nov 24
0
[LLVMdev] Uninitialized variable - question
I think that the relevant part in C11 is section 6.2.6.1, which tells you that accessing a trap representation, _other than using a char type_, is undefined. Objects of automatic storage, which don't have an initializer are of indeterminate value, which either is an unspecified value or a trap representation.
> What I found is that with -O2:
> LLVM (trunk) prints both "a" and
2012 Dec 03
2
[LLVMdev] [RFC] 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,