similar to: [LLVMdev] PR17975 and trunk

On 5 December 2014 at 06:49, Sean Silva <chisophugis at gmail.com> wrote: > > > On Wed, Dec 3, 2014 at 4:23 AM, Robert Lougher <rob.lougher at gmail.com> > wrote: >> >> Hi, >> >> In feedback from game studios a common issue is the replacement of >> loops with calls to memcpy/memset. These loops are often >> hand-optimised, and

https://bugs.freedesktop.org/show_bug.cgi?id=69375 Priority: medium Bug ID: 69375 Assignee: nouveau at lists.freedesktop.org Summary: [NV4E] GPU lockup when using chrome/flash QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: taylor_tails at

My understanding is that dynamically linking should pose no problem, but I am no lawyer. On Linux, glibc is also under LGPL license, and LLVM usually links against it. (There is really no need for us to depend on libiconv. If it is deemed to risky, then I can dropped it.) From: Anton Korobeynikov <anton at korobeynikov.info> To: Kai Peter Nacke <kai.nacke at de.ibm.com> Cc:

Confirmed, this is a bug. This define i32* @get_pntr(i32* %p) nounwind uwtable { entry: ret i32* %p } define void @store(i32* %p) noinline nounwind uwtable { entry: %call = call i32* @get_pntr(i32* %p) store i32 10, i32* %call, align 4 ret void } run through opt -functionattrs gets a 'readnone' on @store's %p. That's wrong, it clearly stores to it. The bug is due to

On 23 May 2014 09:42, Robert Lougher <rob.lougher at gmail.com> wrote: > Hi Nick, > > Thanks for replying. Bug filed: > http://llvm.org/bugs/show_bug.cgi?id=19842 Thank you! Strangely enough, my first conclusion was that %p was being marked > readnone incorrectly as it wasn't handling the copy via @get_addr. > Sorry -- saying %p alone is ambiguous because

Hi! Implementing the Memory::allocateMappedMemory() function on z/OS, I see a failure in the AArch64 COFF test case. The test case has 3 sections. For each section, Memory::allocateMappedMemory() is called to reserve memory. If the distance between the pointers gets too large, then the test case fails. It can be reliable produced with a distance of 1MB between the pointers. An easy way to

On 05/21/2014 02:52 PM, Robert Lougher wrote: > On 21 May 2014 21:40, Robert Lougher <rob.lougher at gmail.com> wrote: >> define i32* @get_pntr(i32* readnone %p) { >> entry: >> ret i32* %p >> } >> >> define void @store(i32* nocapture readnone %p) { >> entry: >> store i32 10, i32* %p, align 4, !tbaa !1 >> ret void >> }

Hi, I'm investigating a bug which I have so far been able to narrow down to the following small testcase: ======== test.c =========== int *get_pntr(int *p) { return p; } __attribute__((noinline)) void store(int *p) { int *p2 = get_pntr(p); *p2 = 10; } int test() { int i; store(&i); return i; } ----------------------------- If this is compiled in two steps as

Hi, In feedback from game studios a common issue is the replacement of loops with calls to memcpy/memset. These loops are often hand-optimised, and highly-efficient and the developers strongly want a way to control the compiler (i.e. leave my loop alone). The culprit is of course the loop-idiom recognizer. This replaces any loop that looks like a memset/memcpy with calls. This affects loops

Hi! On z/OS, there is the need to convert strings from EBCDIC to UTF-8 and vice versa. Using the POSIX iconv functions has some challenges, so I created a small wrapper around this functionality to get the same result on all platforms. This functionality is required for reading and writing GOFF object files and can also be used in the frontend. I put up the code on Phabricator

On 2 December 2014 at 19:57, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Tue, Dec 02, 2014 at 07:23:01PM +0000, Robert Lougher wrote: >> In feedback from game studios a common issue is the replacement of >> loops with calls to memcpy/memset. These loops are often >> hand-optimised, and highly-efficient and the developers strongly want >> a way to

Hello R users, I have a little problem with a for loop. Below there is an simple example of my problem. I want to delet the commas in the character string. Fore this reason I create a for loop to unpick the string and rebuild him without the commas. The problem is, that "paste" does not work in the loop as I expected. text <- "aaa,bbb,ccc,ddd" characterseq <-

On 11 December 2013 05:41, Kai Nacke <kai.nacke at redstar.de> wrote: > Maybe we should also change the stack probing code. I think ___chkstk_ms is > used since gcc 4.6. It simplifies the prologue generation code a bit. I just checked gcc 4.6 and looks like you are right, it uses ___chkstk_ms. LGTM. We should probably commit this first, since it is common for gcc 4.6 and newer.

On Fri, Sep 5, 2014 at 9:32 AM, Robert Lougher <rob.lougher at gmail.com> wrote: > Unfortunately, another team, while doing internal testing has seen the > new path generating illegal insertps masks. A sample here: > > vinsertps $256, %xmm0, %xmm13, %xmm4 # xmm4 = xmm0[0],xmm13[1,2,3] > vinsertps $256, %xmm1, %xmm0, %xmm6 # xmm6 = xmm1[0],xmm0[1,2,3] >

Hubert Tong <hubert.reinterpretcast at gmail.com> wrote on 10.06.2020 23:51:54: > From: Hubert Tong <hubert.reinterpretcast at gmail.com> > To: Kai Peter Nacke <kai.nacke at de.ibm.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Date: 10.06.2020 23:52 > Subject: [EXTERNAL] Re: [llvm-dev] RFC: Adding support for the z/OS > platform to LLVM and clang

There are a large number of ways to lose information in translating loops into memset/memcpy calls, alignment is one of them. As previously mentioned, loop-trip-count is another. Another is size of accesses. For example, the loop may have originally been using int64_t sized copies. This has definite impact on what the best memset/memcpy expansion is, because effectively, the loop knows that it

Hi all! On x86_64, segment prefix fs: is in address space 257 and gs: in address space 256. (BTW: are there constants for these magic values?) How can I use this in IR? I want to express this assembler code in IR: mov RAX, 8; mov RAX, GS:[RAX]; ret; I tried the following: define i64 @getStackBottom(i64 %addr) { entry: %ptr = inttoptr

Howdy, Was there ever a fix for this? I have Trix 2.6 running asterisk 1.4 and have to set an extension with call-limit=1. However that user can no longer do attended transfers from Linkys 962 ip phone. Is there anyway around this? Cheers, Taff..

On 3 Dec 2014, at 23:36, Robert Lougher <rob.lougher at gmail.com> wrote: > On 2 December 2014 at 22:18, Alex Rosenberg <alexr at leftfield.org> wrote: >> >> Our C library amplifies this problem by being in a dynamic library, so the >> call has additional overhead, which for small trip counts swamps the >> copy/set. >> > > I can't imagine

I've run the SingleSource test suite for core-avx-i and have no failures here so a preprocessed file + commandline would be very useful if this reproduces for you still. On Sat, Sep 6, 2014 at 4:07 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > I'm having trouble reproducing this. I'm trying to get LNT to actually > run, but manually compiling the given source