similar to: [LLVMdev] creating a loop in lowering code

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 Steve, Thanks for confirming that EXTRACT_ELEMENT is something I can use. I had seen it in the generated DAGs but was unsure whether I was "allowed" to use it, if that's the right word. I checked up on it more and indeed the mainstream targets like ARM use that node type in custom lowering code, so that should solve that. Perhaps in the future I might submit a patch for

It appears impossible to match memory-to-memory instructions (except for MOV). The MSP430 supports these. The following test case tries to match the pattern that generates "add.w &foo,&bar": ; RUN: llvm-as < %s | llc -march=msp430 -O3 target datalayout = "e-p:16:8:8-i8:8:8-i16:8:8-i32:8:8" target triple = "msp430-generic-generic" @foo = common global

I forgot to mention that I used EXTRACT_ELEMENT in my backend to get the high and low parts of an SDValue. On 10 Nov 2013, at 17:50, Steve Montgomery <stephen.montgomery3 at btinternet.com> wrote: > I had a similar problem with a backend for the 68HC12 family which also has no barrel shifter. Some 68HC12 CPUs support shift for just one of the 16-bit registers and only support rotation

Hi Eli, Thanks for pointing to the CTLZ_ZERO_UNDEF “LibCall” implementation. I have not it in the version that I am currently using, so it’s nice to know that it’s implemented now. Incidentally, the CTLZ… implementation is IDENTICAL to what I am proposing for the Shifts. This is not just adding support for “out-of-tree-targets”, but giving consistency to the fact that we have perfectly defined

I think I have read that there are plans to generate object code (e.g. ELF) directly in addition to assembly language source. If so, are there plans to support branch relaxation for targets which support long/short branch displacements? This is typically done in assemblers. thanks, bagel

Hi, I am trying to complete the hardware multiplier option for MSP430 backend. As the hardware multiplier in most of the MSP430 devices is for i8 and i16 operands, with i16 and i32 result, I am lowering MUL_i8 and MUL_I16. However, the front-end promotes the i8 argument to i32, executes 32-bit multiplier and truncates to 16-bit, so I never lower MUL_I8 nor MUL_I16 but MUL_I32, wchich is lowered

Is anyone working on supporting additional targets used in embedded systems. I am particularly interested in two: 1. TI MSP430. http://en.wikipedia.org/wiki/TI_MSP430 A nice very low power 16-bit machine with a PDP-11-like instruction set. We can assume the PIC16 developers have found and fixed all the 32-bit assumptions in the code base. Newer versions, the MSP430X series, have

> At -O0, you don't. __mulsi3 is the obvious lowering, and you're doing > something wrong if your tools don't provide it. MSP430 is 16 bit target, so mulsi is a bit expensive there, mulhi / mulqi can be implemented via hardware multiplier. There are several problems wrt 16 bit support inside LLVM in general and msp430 in particular: 1. In some places LLVM expectes 32 bit or 64

Any progress on the TI MSP430 target?

On 02/16/2017 12:08 PM, Stephen Canon wrote: >> On Feb 16, 2017, at 9:12 AM, Bagel <bagel99 at gmail.com >> <mailto:bagel99 at gmail.com>> wrote: >> >> I figured that the optimization of this would bedifficult (else it would >> have already been done :-)) > > Don’t make this assumption. There’s lots of opportunities for optimization > scattered

ARM has its own pass to do this (ARMConstantIslandPass.cpp). At some point of time we'd like to rip out the branch relaxation part and make it into a target independent pass. Evan On Aug 13, 2009, at 10:02 AM, Bagel wrote: > I think I have read that there are plans to generate object code > (e.g. ELF) > directly in addition to assembly language source. If so, are there

> On Feb 21, 2017, at 9:54 PM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I believe that providing additional intrinsics that would directly produce the ISD::ADDC/ISD::SUBC nodes would provide the additional advantage of being able to directly produce these nodes for code that doesn't have anything to do with multiprecision addition/subtraction. I am

On 23 November 2010 18:03, Bagel <bagel99 at gmail.com> wrote: > Would someone be so kind as to tell me what the status of debugging symbols > (DWARF) generated by clang/llvm is? Hi Bagel, It should be fairly complete... > When I generate an executable with "clang -g" followed by "llc -O0" and feed it > to gdb, I get "no debugging symbols found".

The following causes an assertion in recent svn pulls, but not in 2.5. The assertion: llvm-as: /home/bgl/work/llvm-work/include/llvm/ADT/SmallVector.h:125: T& llvm::SmallVectorImpl<T>::operator[](unsigned int) [with T = llvm::Constant*]: Assertion `Begin + idx < End' failed. The .ll code: target datalayout =

Dear All, I am working on a back-end implementation for a new architecture which is provided with its own assembler. I am currently capable of writing most of the lowering process to generate a decent assembly code. Under certain circumstances, i.e. depending on the C code, some IR instructions generate a Selection DAG for which I am not implementing a proper lowering, thus resulting in the

Would someone be so kind as to tell me what the status of debugging symbols (DWARF) generated by clang/llvm is? I am on a linux x86-64 system (Fedora 13). Is gdb supposed to understand the generated DWARF? When I generate an executable with "clang -g" followed by "llc -O0" and feed it to gdb, I get "no debugging symbols found". What is the status of lldb on

On Wed, Jun 20, 2012 at 01:50:51PM +0000, Christian Nastasi wrote: > Dear All, > I am working on a back-end implementation for a new architecture which is provided with its own assembler. > I am currently capable of writing most of the lowering process to generate a decent assembly code. > Under certain circumstances, i.e. depending on the C code, some IR instructions generate a

On 12/03/2010 06:28 PM, Devang Patel wrote: > We are working on a document. Here is current draft: > http://wiki.llvm.org/Debug_Information > > - > Devang While this is great news, it doesn't completely satisfy my needs. Your documentation assumes one is going to use the LLVM provided functions (such as DIFactory::). My front-end can't use them because it is not

Dear Tom, thank you for your reply. What you suggest is something I was considering doing, however there still no solution to my Problem2. How do I test the ISD instructions if I can only write IR instructions? -----Original Message----- From: Tom Stellard [mailto:thomas.stellard at amd.com] Sent: Wednesday, June 20, 2012 4:14 PM To: Christian Nastasi Cc: llvmdev at cs.uiuc.edu Subject: Re: