similar to: [LLVMdev] Implementing stack frames/vaargs

Chris Lattner wrote: > Cool! I'm glad to see progress on the sparc backend: > > +++ lib/Target/Sparc/AsmPrinter/SparcAsmPrinter.cpp (working copy) > @@ -44,6 +44,8 @@ > > namespace { > class VISIBILITY_HIDDEN SparcAsmPrinter : public AsmPrinter { > + DwarfWriter *DW; > + > > This shouldn't be needed, the AsmPrinter base class now has this.

On Tue, 29 Mar 2005, Andrew Lenharth wrote: > So Alpha and some other potential targets (amd64?) use structs for > va_list. This is very much at odds with the current instructions and > intrinsics. Yes, this is a serious issue. > And given that, can the 1.0 conversion code be dropped? Yes, 1.0 is dead. Assuming people have 1.1 (and removing the code for dealing with 1.0) or later

So Alpha and some other potential targets (amd64?) use structs for va_list. This is very much at odds with the current instructions and intrinsics. So the question for the community is how much backwards compatibility should be maintained for vaargs? Essentially the behavior needs to be reverted to LLVM 1.0 semantics for vaarg instructions. Currently there is conversion code to convert the old

I'm generating code for a target that only supports i32 natively. My front end is generating VAARG for accessing varargs parameters. The problem is that I get an assert when I compile this: #include <stdarg.h> int main(va_list ap) { typedef double type; type tmp; tmp = va_arg(ap, type); } Bitcode: ; ModuleID = 't0056.bc' target datalayout =

[~/ellcc/test/source] main% cat printf.c #include <stdio.h> int main(int argc, char** argv) { printf("printf with the string \"%s\"\n", "my string"); } [~/ellcc/test/source] main% ~/ellcc/ellcc/x86-elf-ecc printf.c [~/ellcc/test/source] main% ./a.out printf with the string "my string" [~/ellcc/test/source] main% size a.out text data bss

Hi everyone, I'm implementing varags handling for PPC32 with the ELF ABI. It is largely more complicated than the Macho ABI or x86 because it manipulates a struct instead of a direct pointer in the stack. You can find the layout of the va_list struct at the end of this mail. A VAARG call requires a lot of computation. Typically the C code for va_arg(ap, int) is: int va_arg_gpr(ap_list

Stripf, Timo wrote: > I thought the LLVM IR is target independent and that "llvm-gcc -c -emit-llvm -O2" produces target independent code. > > I'm working on a back-end and use llvm-gcc to first generate the bc file. Afterwards I use llc including the new back-end to produce the assembler file. > > -Timo LLVM IR is very target dependent. The IR knows about things

Hi Chris, Chris Lattner wrote: > On Tue, 3 Apr 2007, Nicolas Geoffray wrote: > >> A VAARG call requires a lot of computation. Typically the C code for >> va_arg(ap, int) >> > > If you use va_arg in C, are you seeing llvm.vaarg in the output .ll file? > I'm guessing that if you're asking, then no llvm.vaarg is generated. I can not test it on my

On Tue, 3 Apr 2007, Nicolas Geoffray wrote: > A VAARG call requires a lot of computation. Typically the C code for > va_arg(ap, int) If you use va_arg in C, are you seeing llvm.vaarg in the output .ll file? -Chris > is: > > int va_arg_gpr(ap_list ap) { > int idx = ap->gpr; > if (idx < 8) { > ap->gpr = idx + 1; > return

The code given below worked well. However, the problem is that when I typed dir1 to see the results I found that R order the files as: [1] "data1.flt" "data10.flt" "data100.flt" "data101.flt" [5] "data102.flt" "data103.flt" "data104.flt" "data105.flt" [9] "data106.flt" "data107.flt"

Hello all, The performance comparison between Polly's Cloog and ISL code generator is posted on http://188.40.87.11:8000/db_default/v4/nts/59?compare_to=58&baseline=58 It seems their execution-time performance are comparable: Performance Regressions - Execution Time  (ISL over Cloog) MultiSource/Benchmarks/TSVC/ControlFlow-flt/ControlFlow-flt 8.49%

Hello, I was interested in how much Type-Based Alias Analysis helps to optimize code. For that purpose, I've compared three sets of benchmarks: compiled without TBAA, compiled with a default TBAA metadata format, and compiled with new TBAA metadata format. As a set of benchmarks, I've used the LLVM test suite (http://llvm.org/docs/TestingGuide.html#test-suite-overview) which has a lot of

Hi, Below you can see the updated benchmark results for the new SLP-vectorizer. As you can see, there is a small number of compile time regressions, a single major runtime *regression, and many performance gains. There is a tiny increase in code size: 30k for the whole test-suite. Based on the numbers below I would like to enable the SLP-vectorizer by default for -O3. Please let me know if you

The newlib C library provides iprintf(), a restricted version of printf without support for floating-point formatting. I'd like to add an optimization which turns calls to printf() into calls to iprintf() if the format string has no floating point specifiers. At the moment I've got this working locally by adding code to the simplify-libcalls pass. However this will break on targets

Sorry for not posting sooner. I forgot to send an update with the results. I also have some benchmark data. It confirms much of what you posted -- binary size increase is essentially 0, performance increases across the board. It looks really good to me. However, there was one crash that I'd like to check if it still fires. Will update later today (feel free to ping me if you don't hear

Hello user-list, Here is my pb : I have a brand new debian Etch with all updates installed on a DELL PE SC430 with a Pentium D 930 (3Ghz, Intel-VT, EMT64) I''ve downloaded xen-3.3 and tried to install with /*"The Perfect Xen 3.1.0 Setup For Debian Etch" */howto. But when i run the the "make world" I have an error with the studbom compilation : /Dans le fichier

On Sep 6, 2009, at 1:34 PM, Richard Pennington wrote: > Please review the enclosed patch for Sparc debug info. > I have been able to view source files, set breakpoints, and single > step source lines after applying this patch. I can't view variables > because I haven't implemented Dwarf type data, yet. Cool! I'm glad to see progress on the sparc backend: +++

Hi, Sean: I'm sorry I lie. I didn't mean to lie. I did try to avoid making a *BIG* change to the IPO pass-ordering for now. However, when I make a minor change to populateLTOPassManager() by separating module-pass and non-module-passes, I saw quite a few performance difference, most of them are degradations. Attacking these degradations one by one in a piecemeal manner is wasting

Please review the enclosed patch for Sparc debug info. I have been able to view source files, set breakpoints, and single step source lines after applying this patch. I can't view variables because I haven't implemented Dwarf type data, yet. -Rich -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sparcdebug.patch URL:

On Feb 2, 2011, at 10:11 AM, Richard Osborne wrote: > The newlib C library provides iprintf(), a restricted version of printf > without support for floating-point formatting. I'd like to add an > optimization which turns calls to printf() into calls to iprintf() if > the format string has no floating point specifiers. Cool, ok. I can see how this would be very useful for a