search for: instructionselection

Thanks Kristof. Sounds like we'll need to investigate though I'd say it is not blocking the switch. At this point I think everybody is on board to flip the switch. @Eric, how does that sound to you? Thanks, Q > Le 1 juin 2017 à 07:46, Kristof Beyls <Kristof.Beyls at arm.com> a écrit : > > >> On 31 May 2017, at 17:07, Quentin Colombet <qcolombet at

Hi all, I added a buildbot [1] running the test-suite with -O0 -global-isel. It runs into the same 2 timeouts that I reported previously on this thread (paq8p and scimark2). It would be nice to make it green before flipping the switch. At the moment, it lives in an internal buildmaster that I've setup for this purpose. If we fix it and it proves to be stable for a week or two, I'll move

Hi, I've been experimenting with global isel over the last few weeks and it is such a vast improvement over the SelectionDAG for the AMDGPU target that I would really like to begin using it as soon as possible. Given the lack of a replacement for SelectionDAG's legalizer / combiner, and how much work this will be to implement, I think the fastest path to doing this would be to run some

Hi Kristof, Thanks for the updated numbers. > On May 31, 2017, at 7:45 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > >> >> On 31 May 2017, at 15:33, Diana Picus via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Cool test :) >> It seems to work fine now, I don't see any new failures.

On 12 June 2017 at 18:54, Diana Picus <diana.picus at linaro.org> wrote: > Hi all, > > I added a buildbot [1] running the test-suite with -O0 -global-isel. It > runs into the same 2 timeouts that I reported previously on this thread > (paq8p and scimark2). It would be nice to make it green before flipping the > switch. > > I did some more investigations on a machine

Hi, Chris Lattner wrote: > In the 2.3 release, we included a list of the major LLVM API changes. If you > are working on upgrading your code from 2.3 to 2.4, I'd appreciate it if you > could compile a list of the major stumbling blocks you have, so that others > can benefit from your experience. Please send any info to the list, thanks! No major stumbling blocks during our

In the 2.3 release, we included a list of the major LLVM API changes. If you are working on upgrading your code from 2.3 to 2.4, I'd appreciate it if you could compile a list of the major stumbling blocks you have, so that others can benefit from your experience. Please send any info to the list, thanks! -Chris

Hi all, Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html, I am sending this email to give a status on GlobalISel progress and situation. We are pushing GlobalISel from the state of prototype to a production quality framework. We welcome help with patches, reviews, feedbacks and so on. As explained during the last developer meeting, we are aiming at

I was under the impression his answer was correct from your reply, no? On Oct 17, 2016 17:45, "Alex Bradley via llvm-dev" <llvm-dev at lists.llvm.org> wrote: > Gentle Ping !! > > I would appreciate any help on this. I want to generate following as > described by Krzysztof : > > %v1 = load i32, i32* %a > %v2 = load i32, i32* %b > %v3 = add i32 %v1, %v2 >

Dan Gohman <gohman at apple.com> writes: > On Mar 15, 2009, at 2:02 PM, Jakob Stoklund Olesen wrote: >> Am I misusing register classes, or is this simply functionality that >> has not been written yet? The existing backends seem to have only one >> register class per machine value type. > > The x86 backend has an example of a partial solution. The GR32 >

LLVM Weekly - #230, May 28th 2018 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/230>. Welcome to the two hundred and thirtieth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

...s. Some target instructions work with specified registers (not all registers in RegisterClass). Often it's one or two registers. I don't understand how use ComplexPattern in this case. But if I don't use ComplexPattern I'll have other problems - not all instruction can select in InstructionSelection pass. My work place here: https://github.com/earl1k/llvm-z80 Example of some load instructions for Z80 CPU with opcode: Opcode Instruction node pattern 0x46 LD $dst,(HL) (set GR8:$dst, (load HL)) 0x0A LD A,(BC) (set A, (load BC))...

On Mar 16, 2009, at 11:31 AM, Jakob Stoklund Olesen wrote: > Dan Gohman <gohman at apple.com> writes: > >> On Mar 15, 2009, at 2:02 PM, Jakob Stoklund Olesen wrote: >>> Am I misusing register classes, or is this simply functionality that >>> has not been written yet? The existing backends seem to have only >>> one >>> register class per

On Mar 15, 2009, at 2:02 PM, Jakob Stoklund Olesen wrote: > Hi, > > I am writing a backend for the Blackfin processor from Analog > Devices. I > just started so I still have a lot to learn about the code > generator. So > far, I can compile test/CodeGen/Generic/BasicInstrs.ll correctly, but > that is about it. > > The Blackfin 32-bit registers divide naturally

Hi all, opt and opt + llc generate the difference aarch64 asm code for the following LLVM code. Is it intended behavior? I expected (A) because I cast %p from i192* to i64*. The information is dropped by opt and 8-byte padding is inserted or I write a bad code? % cat a.ll define void @store0_to_p4(i192* %p) { %p1 = bitcast i192* %p to i64* %p2 = getelementptr i64, i64* %p1, i64 3 %p3 =

Hi, I am writing a backend for the Blackfin processor from Analog Devices. I just started so I still have a lot to learn about the code generator. So far, I can compile test/CodeGen/Generic/BasicInstrs.ll correctly, but that is about it. The Blackfin 32-bit registers divide naturally into several classes. I have modelled these register classes without knowing anything about what the code

Cool test :) It seems to work fine now, I don't see any new failures. IIUC, Kristof is also giving it another run. Cheers, Diana On 30 May 2017 at 22:57, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Diana, > > I’ve actually gone ahead and pushed the fix as I was able to produce a > small reproducer. > > This is r304244 > > Let me know if you encounter