similar to: [LLVMdev] Genlibdeps.pl, CMake and MSYS

Kenneth Boyd <zaimoni at zaimoni.com> writes: >> I'm seeing a failure related to circular library references while >> building LLVM with CMake and MSYS. This didn't happen on the >> past. Building with the configure script works, so it seems something >> related to CMake. Do you have any insight on this? >> > I'll get back on this tonight or

Óscar Fuentes wrote: > Kenneth Boyd <zaimoni at zaimoni.com> writes: > >> * I am seeing desynchronization between the configure-generated >> Makefiles and the CMakeFile.txt files. [e.g., llc; makefile doesn't >> have asmprinter, CMakeFile.txt does]. That much I should be able to >> construct a patch for "blind", if no-one gets to it first.

Óscar Fuentes wrote: > Kenneth Boyd <zaimoni at zaimoni.com> writes: > > [snip] > >> My internal priority for that CMake patch is low, as I need only minimal >> patching to use the autoconf-generated configure script to build LLVM. >> Right now it's just llvm.config.in.in that needs patching (the failsafed >> GenLibDeps.pl script went in

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 =

Kenneth Boyd <zaimoni at zaimoni.com> writes: >>> * I am seeing desynchronization between the configure-generated >>> Makefiles and the CMakeFile.txt files. [e.g., llc; makefile doesn't >>> have asmprinter, CMakeFile.txt does]. That much I should be able to >>> construct a patch for "blind", if no-one gets to it first. >>>

Kenneth Boyd <zaimoni at zaimoni.com> writes: [snip] >> That does not really surprise me about CMake, but then mingw is not a >> primary compiler on Windows, more so is VC++ or Intel, either way a >> bug should be submitted to the CMake devs. > I do not want to troll the CMake devteam, so I will not submit the bug > report without a full-blown patch. The CMake

Óscar Fuentes wrote: > The CMake devteam is very responsive about bug reports. They will > certainly appreciate your bug report, no patch required. > I still don't think I have enough detail to file a bug report (not sure exactly what they need to know about my system configuration to make it testable). I did go ahead (just now) and ask the main CMake mailing list which files I

> >> d) Would it be possible with current implementation of soft-float >> support to map f32/f64 to integer types smaller than i32, e.g. to >> i16? >> I have the impression that it is not necessarily the case, since it >> would require that f64 is split into 4 parts. > > Yes, this should be fine. > >> This question is more about a theoretical

On Dec 20, 2006, at 2:06 PM, Roman Levenstein wrote: >> >> This will probably require a slightly more extensive patch to >> legalizer. The current mechanism assumes either 1->1 or 1->2 >> expansion. > > Exactly. This is what I meant with "more chellenging";) It is assumed > at several places that 1->1 or 2->2 expanstions are taking place. A

> >> d) Would it be possible with current implementation of soft-float > >> support to map f32/f64 to integer types smaller than i32, e.g. to > > >> i16? > >> I have the impression that it is not necessarily the case, since > it would require that f64 is split into 4 parts. > > > > Yes, this should be fine. > > > >> This

Hi, I was working on extending soft-float support for handling expansion of i64 and f64 into i16, i.e. on supporting the expansion of long values of illegal types into more then two parts. For that I modified SelectionDAGLowering::getValue() and several other functions. This seems to work now on my test-cases, but while testing it I ran into a different problem. I have the impression that I

Hi I found utils/GenLibDeps.pl cann't run on Windows, so I fix it, made a patch on svn-110435. I submit this patch, hope it can be accepted. Thanks for your time. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100806/d2e10f3e/attachment.html> -------------- next part -------------- A

Hello > I found utils/GenLibDeps.pl cann't run on Windows, so I fix it, made a patch > on svn-110435. I submit this patch, hope it can be accepted. It definitely works for me on windows (not only for me, but for many others too). Which problems you're seeing? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

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

When I use clang on an x86-64 to spit out the LLVM, like this clang -O -S -emit-llvm varargstest.c where varargstest.c looks like this int add_em_up(int count, ...) { va_list ap; int i, sum; va_start(ap, count); sum = 0; for (i = 0; i < count; i++) sum += va_arg(ap, int); va_end(ap); return sum; } I see LLVM that looks like it's been customized for the x86-64, versus

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

Hi, I'm trying to build clang under MingW, but I'm getting a number of errors. Could anyone provide some hints as to what you had to do? I got some tips from http://blogs.tedneward.com/2008/02/24/Building+LLVM+On+Windows+Using+MinGW32.aspx, but using the newer packages, as it's a bit old. The ./configure seems to run without errors. The first run of make aborts with errors like:

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

# The future of the va_arg instruction ## Summary LLVM IR currently defines a va_arg instruction, which can be used to access a vararg. Few Clang targets make use of it, and it has a number of limitations. This RFC hopes to promote discussion on its future - how 'smart' should va_arg be? Should we be aiming to transition all targets and LLVM frontends to using it? ## Background on va_arg