similar to: [LLVMdev] Quest for more targets

> 1. TI MSP430. http://en.wikipedia.org/wiki/TI_MSP430 I'm also very interested in an msp430 backend. I had been considering seeing if I could hack out a first draft over winter break. This would be very useful to one of my students who is currently stuck doing things in gcc. The msp430 port of gcc is not closely maintained and seems quite buggy. > 2. ARM Cortex M3. This would

Any progress on the TI MSP430 target?

Hi, I'm looking for some pointers on how to troubleshoot this problem. I'm trying to write a backend for the AVR. There is an undefined reference at line 48 which is the line FrameInfo() is on. I've tried to use the MSP430 and other targets as references so I'm not sure what changes I did would cause a problem on this line? AVRTargetMachine::AVRTargetMachine(const Target &T,

Hi All, While implementing a custom 16 bit target for academical and demonstration purposes, I unexpectedly found that LLVM was not really ready for 8 bit and 16 bit targets. Let me expose why. Target backends can be divided into two major categories, with essentially nothing in between: Type 1: The big 32 or 64 bit targets. Heavily pipelined with expensive branches, running at clock

John Myers <atomicdog.jwm at gmail.com> writes: > I'm looking for some pointers on how to troubleshoot this problem. I'm > trying to write a backend for the AVR. > There is an undefined reference at line 48 which is the line FrameInfo() is > on. I've tried to use the MSP430 and other targets as references so I'm not > sure > what changes I did would cause a

Hello, We have the architecture without conditional moves. Which way can we lower select? As we know there was the special pass a long time ago, but it was deleted. commit c3591a0d48ce045bbf5ae0d78a41f3dae4bb99db Author: Chris Lattner <sabre at nondot.org> Date:   Tue Feb 19 07:49:17 2008 +0000     remove the LowerSelect pass.  The last client was the old Sparc backend, which is long

On Wed, Nov 13, 2019 at 12:26 PM Joan Lluch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi All, > > In relation to the subject of this message I got my first round of patches successfully reviewed and committed. As a matter of reference, they are the following: > > https://reviews.llvm.org/D69116 > https://reviews.llvm.org/D69120 >

Hi Eli, First of all, please I would appreciate that you try to not confuse my limited use of English with stupidity or lack or criteria in other subjects. I’m not English native, so please keep that in mind. You have been significantly helpful in the recent past so please keep on. Interestingly, you made a mention of a related but not identical issue. It is true that most (or all) processors

Hi Sanjay, Thanks for your reply. > So yes, the IR optimizer (instcombine is the specific pass) sometimes turns icmp (and select) sequences into ALU ops. Instcombine is almost entirely *target-independent* and should remain that way. The (sometimes unfortunate) decision to create shifts were made based on popular targets of the time (PowerPC and/or x86), and other targets may have suffered

As before, I'm not convinced that we want to allow target-based enable/disable in instcombine for performance. That undermines having a target-independent canonical form in the 1st place. It's not clear to me what the remaining motivating cases look like. If you could post those here or as bugs, I think you'd have a better chance of finding an answer. Let's take a minimal example

Hello, I have successfully build the newest llvm from git source, and I would like to do some experiments on target AVR. Does "make check-all" cover AVR? All I need some extra steps to test AVR? I have neither AVR simulator nor real AVR board connected. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Changing the order of the checks in CodeGenPrepare::optimizeSelectInst() sounds good to me. But you may need to go further for optimum performance. For example, we may be canonicalizing math/logic IR patterns into 'select' such as in the recent: https://reviews.llvm.org/D67799 So if you want those to become ALU ops again rather than branches, then you need to do the transform later in

For any of the examples shown below, if the logical equivalent using cmp + other IR instructions is no more than the number of IR instructions as the variant that uses shift, we should consider reversing the canonicalization. To make that happen, you would need to show that at least the minimal cases have codegen that is equal or better using the cmp form for at least a few in-tree targets. My

Hi all, > On 2 Oct 2019, at 14:34, Sanjay Patel <spatel at rotateright.com> wrote > Providing target options/overrides to code that is supposed to be target-independent sounds self-defeating to me. I doubt that proposal would gain much support. > Of course, if you're customizing LLVM for your own out-of-trunk backend, you can do anything you'd like if you're willing to

In -help output, -help - Display available options (--help-hidden for more) Both single and double - option markers are accepted, which is good. It would probably be better to refer to options consistently using the single marker in all cases. =linearscan - linear scan register allocator =pbqp - PBQP

On Mon, Sep 30, 2019 at 11:52 AM Joan Lluch <joan.lluch at icloud.com> wrote: > > Hi Roman, > > Is "test" actually an implementation of a 64-bit-wide multiplication > compiler-rt builtin? > Then i'd think the main problem is that it is being optimized in the > first place, you could end up with endless recursion… > > > No, this is not a compiler-rt

Hello, I would like to know if the ARM architecture is well supported. At Xen.org it is mentionned in available architectures, but does it work really well ? I''m looking at CPU like "Tile64" from Tilera : http://www.tilera.com/products/processors/TILE64 The wiki http://wiki.xensource.com/xenwiki/XenARM doesn''t seem to be up to date. Is it ? Any advice ? Thanks,

I have been analyzing the implementation for some backend (PIC16, MIPS, SPARC and MSP430) my main problem is that they are so much different, I mean obviously they are describing different architectures, but the file structure is not the same. So it is difficult to get a pattern. I have checked the available documentation files, also the video from Cardoso about how to write a backend for the

On Sun, Sep 29, 2019 at 3:35 PM Joan Lluch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Sanjay, > > Actually, the CodeGenPrepare::optimizeSelectInst is not doing the best it could do in some circumstances: The case of “OptSize" for targets not supporting Select was already mentioned to be detrimental. > > For targets that actually have selects, but branches

Hi Vikram, I think it's worth continuing to discuss this on-list. I'm interested in different kinds of embedded software, but specifically in TinyOS applications. > We (more accurately, John Criswell and Brice Lin) are working on a > debugging version of SAFECode right now, which should be robust enough > to play with soon. This is great to hear. I know the SAFECode paper