similar to: [LLVMdev] project page request

It appears the syntax for returning multiple values has changed since 2.9. Previous to that: ret i32 %a, i32 %b worked. The new syntax is something like: ret { i32, i32 }{i32 %a, i32 %b} but this yields an error: mrv-bug.ll:5:24: error: invalid use of function-local name ret { i32, i32 }{i32 %a, i32 %b} ^ If %a and %b are replaced by constants, things work. Am I

On 06/24/2011 03:45 PM, Chris Lattner wrote: > > On Jun 24, 2011, at 9:29 AM, Bagel wrote: > >> It appears the syntax for returning multiple values has changed since 2.9. >> Previous to that: >> ret i32 %a, i32 %b >> worked. The new syntax is something like: >> ret { i32, i32 }{i32 %a, i32 %b} >> but this yields an error: >> mrv-bug.ll:5:24:

I have developed a new systems programming language called ESL (Embedded Systems Language). The compiler for it is a front end to LLVM and is written in itself, bootstrapping via LLVM assembly code. Most of the language is ordinary, but some things that aren't: no reserved words, procedures can return multiple values, data types allow the exact placement of bits, alignment, and

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

On Jun 24, 2011, at 2:21 PM, Bagel wrote: >> This is obsolete and deprecated syntax that is dropped in "llvm 3.0" (and thus on mainline right now). If you run that through llvm-as|llvm-dis from llvm 2.9, you'll see the preferred syntax. >> >> -Chris > > OK, I guess I missed the announcement that it was obsolete. It will eventually be in the llvm 3.0

> 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

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

It takes two "llvm.uadd.with.overflow" instances to model the add-with-carry when there is a carry-in. Look at the IR generated by the example. I figured that the optimization of this would bedifficult (else it would have already been done :-)). And would this optimization have to be done for every architecture? On 02/15/2017 04:28 PM, Stephen Canon wrote: > > Why do you think

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".

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

I am writing a backend for an experimental machine that has both 2-address and 3-address versions of some instructions. The 2-address versions are more compact and thus preferred when applicable. How does one go about generating the most compact version? 1. At instruction selection, is there a predicate that can test whether one of the input sources is dead, thus allowing the selection of the

On 09/11/2014 05:33 PM, Quentin Colombet wrote: > Hi Brian, > > On Sep 11, 2014, at 3:03 PM, Bagel <bagel99 at gmail.com> wrote: > >> When the IR specifies a 32 bit load can it be changed to a narrower >> load? What if the load is from memory (e.g. a peripheral) that only >> supports 32-bit access? Consider the following IR: ---- target datalayout >> =

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 =

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

I propose a new intrinsic "llvm.memcmp" that compares a block of memory for equality (a subset of the libc behavior). Backends are free to use the alignment to optimize using wider than byte operations. Since the result is only equal/not-equal, byte order is not important. For languages that support array compares, this would be very useful. Syntax: declare i1 @llvm.memcmp(i8*

On 4 December 2010 21:16, bagel <bagel99 at gmail.com> wrote: > Perhaps you can add another section just on the textual format? Oh, perhaps you're looking for this: http://llvm.org/docs/SourceLevelDebugging.html cheers, --renato

When the IR specifies a 32 bit load can it be changed to a narrower load? What if the load is from memory (e.g. a peripheral) that only supports 32-bit access? Consider the following IR: ---- target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:32" target triple = "thumbv7m-unknown-unknown" @f = external global i32 define zeroext i8 @bar() nounwind { L.0:

Assume an architecture that has multiple condition code registers, e.g., powerpc. Now assume that there are predicate instructions like thumb2, but can specify which condition code register they refer to. Now also assume that these predicate instructions themselves are predicatible, if executed they change the current predication state. Can LLVM handle multiple levels of predication? When is

When addresses are a displacement from a constant (this can happen in device drivers), the resulting address gets folded rather than using base+displacement addressing. This results in code bloat. Example test attached. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: const-addr.ll URL:

On Jun 24, 2011, at 9:29 AM, Bagel wrote: > It appears the syntax for returning multiple values has changed since 2.9. > Previous to that: > ret i32 %a, i32 %b > worked. The new syntax is something like: > ret { i32, i32 }{i32 %a, i32 %b} > but this yields an error: > mrv-bug.ll:5:24: error: invalid use of function-local name > ret { i32, i32 }{i32 %a, i32 %b} >