- Generating Assembly Code + +

+ +

The code emission step of code generation is responsible for lowering from +the code generator abstractions (like MachineFunction, MachineInstr, etc) down +to the abstractions used by the MC layer (MCInst, +MCStreamer, etc). This is +done with a combination of several different classes: the (misnamed) +target-independent AsmPrinter class, target-specific subclasses of AsmPrinter +(such as SparcAsmPrinter), and the TargetLoweringObjectFile class.

+ +

Since the MC layer works at the level of abstraction of object files, it +doesn't have a notion of functions, global variables etc. Instead, it thinks +about labels, directives, and instructions. A key class used at this time is +the MCStreamer class. This is an abstract API that is implemented in different +ways (e.g. to output a .s file, output an ELF .o file, etc) that is effectively +an "assembler API". MCStreamer has one method per directive, such as EmitLabel, +EmitSymbolAttribute, SwitchSection, etc, which directly correspond to assembly +level directives. +

+ +

If you are interested in implementing a code generator for a target, there +are three important things that you have to implement for your target:

+ +

First, you need a subclass of AsmPrinter for your target. This class +implements the general lowering process converting MachineFunction's into MC +label constructs. The AsmPrinter base class provides a number of useful methods +and routines, and also allows you to override the lowering process in some +important ways. You should get much of the lowering for free if you are +implementing an ELF, COFF, or MachO target, because the TargetLoweringObjectFile +class implements much of the common logic.
Second, you need to implement an instruction printer for your target. The +instruction printer takes an MCInst and renders it to a +raw_ostream as text. Most of this is automatically generated from the .td file +(when you specify something like "add $dst, $src1, $src2" in the +instructions), but you need to implement routines to print operands.
Third, you need to implement code that lowers a MachineInstr to an MCInst, usually implemented in +"<target>MCInstLower.cpp". This lowering process is often target +specific, and is responsible for turning jump table entries, constant pool +indices, global variable addresses, etc into MCLabels as appropriate. This +translation layer is also responsible for expanding pseudo ops used by the code +generator into the actual machine instructions they correspond to. The MCInsts +that are generated by this are fed into the instruction printer or the encoder. +

+ +

Finally, at your choosing, you can also implement an subclass of +MCCodeEmitter which lowers MCInst's into machine code bytes and relocations. +This is important if you want to support direct .o file emission, or would like +to implement an assembler for your target.

To Be Written

- -

- Generating Binary Machine Code + + + +

+ Implementing a Native Assembler

For the JIT or .o file writer

+ +

TODO

From wendling at apple.com Sat Sep 11 19:04:03 2010 From: wendling at apple.com (Bill Wendling) Date: Sat, 11 Sep 2010 17:04:03 -0700 Subject: [llvm-commits] [llvm] r113670 - in /llvm/trunk: include/llvm/Target/TargetInstrInfo.h lib/CodeGen/PeepholeOptimizer.cpp lib/Target/ARM/ARMBaseInstrInfo.cpp lib/Target/ARM/ARMBaseInstrInfo.h In-Reply-To: <39c53e0a-1bff-4c04-96d8-5f68bb0a7ed8@l17g2000vbf.googlegroups.com> References: <20100911001350.9B7AE2A6C12C@llvm.org> <39c53e0a-1bff-4c04-96d8-5f68bb0a7ed8@l17g2000vbf.googlegroups.com> Message-ID: <394A85E5-1552-42D1-A388-E3F734AD65B1@apple.com> On Sep 11, 2010, at 5:43 AM, Gabor Greif wrote: > Bill, > > I tried to extend your approach to TSTri (as an eliminable compare > instr.) and > ANDri (as an implicit compare) with this patch: > That's what I'm attempting to do right now. :-) I want to do a bit more than just replace the TST with an AND that sets CPSR, though that's the first step. I'm introducing a separate callback instruction to handle TST (i.e., comparisons against a non-zero value). > gabor at google8:~/llvm-build$ svn diff /home/gabor/llvm/lib/Target/ARM/ > ARMBaseInstrInfo.cpp > Index: /home/gabor/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp > =================================================================== > --- /home/gabor/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp > (revision 113683) > +++ /home/gabor/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp > (working copy) > @@ -1372,6 +1372,10 @@ > SrcReg = MI->getOperand(0).getReg(); > CmpValue = MI->getOperand(1).getImm(); > return true; > + case ARM::TSTri: > + SrcReg = MI->getOperand(0).getReg(); > + CmpValue = 0; I think the TST instruction can take a compare value other than 0. The CMP instructions take 0, right? > @@ -1421,6 +1425,7 @@ > switch (MI->getOpcode()) { > default: break; > case ARM::ADDri: > + case ARM::ANDri: > case ARM::SUBri: > case ARM::t2ADDri: > case ARM::t2SUBri: > gabor at google8:~/llvm-build$ > > > BUT, it does not trigger on my example, because of > something that appears to be a bug: > > %reg16388 = PHI %reg16396, , %reg16392, ; GPR: > %reg16388,16396,16392 > %reg16389 = PHI %reg16385, , %reg16391, ; GPR: > %reg16389,16385,16391 > %reg16397 = LDR %reg16387, %reg0, 4100, pred:14, pred: > %reg0; mem:LD4[%scevgep1] GPR:%reg16397,16387 > %reg16390 = ANDri %reg16397, 3, pred:14, pred:%reg0, opt: > %reg0; GPR:%reg16390,16397 > TSTri %reg16397, 3, pred:14, pred:%reg0, %CPSR; GPR: > %reg16397 > Bcc , pred:0, pred:%CPSR > > The TST seems to use the result of the LDR instead of that of the AND! > Very fishy... > If you want to use the result of AND instead of TST in the Bcc, you'll need to say that AND implicitly defines CSPR. In the above case, it looks like the AND is basically dead (at least in this code snippet). The TST performs an "and" of the 3 to the result of LDR, which is what the AND instruction does. The only difference here is that TST sets CPSR and the AND doesn't. > The bitcode is ok: > > %tmp2 = load i8** %scevgep1 > %0 = ptrtoint i8* %tmp2 to i32 > %and = and i32 %0, 3 > %tst = icmp eq i32 %and, 0 > br i1 %tst, label %sw.bb, label %tailrecurse.switch > > What do you think? Okay to commit the above? > Below is what I have in my tree right now. It's just the skeleton of how I'd like to handle this (it does nothing right now). I like it because of how it separates out different optimization potentialities for each type of instruction, but it may be overkill... -bw Index: include/llvm/Target/TargetInstrInfo.h =================================================================== --- include/llvm/Target/TargetInstrInfo.h (revision 113706) +++ include/llvm/Target/TargetInstrInfo.h (working copy) @@ -595,6 +595,15 @@ return false; } + /// OptimizeTestInstr - See if the test instruction can be converted into + /// something more efficient. Update the iterator *only* if a transformation + /// took place. + virtual bool OptimizeTestInstr(MachineInstr * /*CmpInstr*/, + unsigned /*SrcReg*/, int /*CmpValue*/, + MachineBasicBlock::iterator &MII) const { + return false; + } + /// getNumMicroOps - Return the number of u-operations the given machine /// instruction will be decoded to on the target cpu. virtual unsigned getNumMicroOps(const MachineInstr *MI, Index: lib/Target/ARM/ARMBaseInstrInfo.cpp =================================================================== --- lib/Target/ARM/ARMBaseInstrInfo.cpp (revision 113706) +++ lib/Target/ARM/ARMBaseInstrInfo.cpp (working copy) @@ -1377,6 +1377,18 @@ return false; } +/// OptimizeTestInstr - See if we can convert the TEST instruction into an +/// equivalent AND instruction, possibly saving an instruction or two if we can +/// make AND set the flags register. +bool ARMBaseInstrInfo:: +OptimizeTestInstr(MachineInstr *CmpInstr, unsigned SrcReg, int CmpValue, + MachineBasicBlock::iterator &MII) const { + if (CmpValue == 0) + return false; + + return false; +} + /// OptimizeCompareInstr - Convert the instruction supplying the argument to the /// comparison into one that sets the zero bit in the flags register. Update the /// iterator *only* if a transformation took place. Index: lib/Target/ARM/ARMBaseInstrInfo.h =================================================================== --- lib/Target/ARM/ARMBaseInstrInfo.h (revision 113706) +++ lib/Target/ARM/ARMBaseInstrInfo.h (working copy) @@ -350,6 +350,13 @@ int CmpValue, MachineBasicBlock::iterator &MII) const; + /// OptimizeTestInstr - See if we can convert the TEST instruction into an + /// equivalent AND instruction, possibly saving an instruction or two if we + /// can make AND set the flags register. + virtual bool OptimizeTestInstr(MachineInstr *CmpInstr, unsigned SrcReg, + int CmpValue, + MachineBasicBlock::iterator &MII) const; + virtual unsigned getNumMicroOps(const MachineInstr *MI, const InstrItineraryData *ItinData) const; }; Index: lib/CodeGen/PeepholeOptimizer.cpp =================================================================== --- lib/CodeGen/PeepholeOptimizer.cpp (revision 113706) +++ lib/CodeGen/PeepholeOptimizer.cpp (working copy) @@ -249,6 +249,12 @@ return true; } + // Attempt to optimize the test instruction. + if (TII->OptimizeTestInstr(MI, SrcReg, CmpValue, NextIter)) { + ++NumEliminated; + return true; + } + return false; } From dgregor at apple.com Sat Sep 11 19:11:05 2010 From: dgregor at apple.com (Douglas Gregor) Date: Sat, 11 Sep 2010 17:11:05 -0700 Subject: [llvm-commits] [PATCH][CMake] Removing LLVMLibDeps.cmake and exporting libraries for CMake clients. In-Reply-To: <87occ3di97.fsf@telefonica.net> References: <87vd6fejb9.fsf@telefonica.net> <470F86A9-0C61-47BF-B12B-1556310BFA55@apple.com> <87occ3di97.fsf@telefonica.net> Message-ID: <2FED81DC-D4AD-47A6-9863-8ACB3C2B5586@apple.com> On Sep 11, 2010, at 3:31 PM, ?scar Fuentes wrote: > Hello Doug. Glad to see my confidence on the sociability of the LLVM > developers restored ;-) :) > Douglas Gregor writes: > >>> Your patch switches from automatic to manually maintained library >>> dependencies. On the case of LLVM, that increases the workload of the >>> maintainer and it is the CMake equivalent of spaghetti code. Only a >>> strong benefit would justify that. >> >> There are numerous benefits to explicitly-maintained library dependencies: >> - It's clear what those dependencies are, which leads to better >> understanding of the system as a wholea > > The file cmake/modules/LLVMLibDeps.cmake concentrates all those > dependencies, so if you want to get the whole picture of the library > dependencies, you have a single point to look at, instead of dozens of > files scattered all around the source tree. If you want the whole picture, it's slightly better to have one large list of dependencies. That said, text is a horrible format for such a task, and it's far more likely that someone wanted to look at the whole picture would actually want a picture, e.g., as generated by GraphViz. I do have a few issues with putting all of the dependencies in a single file: 1) People forget about it when they make changes. LLVM developers have gotten fairly good at updating CMakeLists.txt when they change the corresponding makefile (finally!), because they live alongside the Makefiles. This other file off in an apparently-unrelated subdirectory gets forgotten. 2) Most of the time, we want to reason about dependencies locally ("I added this feature, and now my library depends on..."), and a single file makes that harder. 3) It's unclear how a "single file" works for multiple projects. For example, LLVMLibDeps didn't have Clang's dependencies, because Clang is in a different repository. Should Clang have its own ClangLibDeps? Should they all be merged together? We actually had a mix of LLVMLibDeps dependencies and per-CMakeLists.txt dependencies. > It is possible to make that file more redable, if you wish. > >> - Changes in dependencies, which are fundamentally architectural >> changes, become obvious when they happen > > Again, looking at the history of LLVMLibDeps.cmake you can see all those > changes at a glance. Yes, agreed. >> - Dependencies can make their way into other tools far more >> easily, e.g., component-based CPack installers (e.g., >> http://www.paraview.org/Wiki/CMake:Component_Install_With_CPack) > > CPack works fine with the automatic library dependency system. Please > note that the automatic system ends using target_link_libraries anyways, > so putting it explicitly on the corresponding CMakeLists.txt makes no > difference for tools that require its existente. I'm specifically referring to dependencies in component-based installers, which are separate from those dependencies and can be at a higher level of granularity (e.g., dependencies between groups of libraries in the graphical installer). >> For one, find_package is the standard CMake way of finding a package, >> so we should be providing that to CMake users. > > That sounds good, but we shall think on terms of the specific > characteristics of LLVM. find_package works fine for libraries such as > zlib, that is, components that you install on standard places because > they are required by some other package and which are stable and remain > unchanged until a bug is found or a new version is required. > > I don't think LLVM fits there. Either you have LLVM for working *on* it, > or you are tracking its development. In any case LLVM is not just "a > library," but THE library. And given how LLVM is developed you end > working with it as if it were work-in-progress, i.e. everything but > stable (in the sense of "frozen") not mentioning that you can easily end > with several installs around and wanting to use uninstalled builds > too. AFAIK find_package doesn't shine on those scenarios. My understanding of CMake's export feature is that it helps with this, too; you can use CMake variables to push find_package toward, for example, a build tree of LLVM in your project that depends on LLVM. > For the average user, I don't think that find_package offers significant > advantages over the method documented in > > http://www.llvm.org/docs/CMake.html#embedding I think the advantage is familiarity; we'd fit better into the general CMake ecosystem if we follow their conventions. > That said, I *think* that the automatic library dependencies system is > not an impediment for supporting find_package. No, it should be separate. Indeed, these two pieces of the patch (dependencies changes and export changes) should have been separated. >> CMake's export is designed to make it easy to get find_package working >> well, with versioning, the ability to directly depend on the exported >> project's targets, etc. One huge benefit to doing >> exporting/find_package well is that it would make it easier to >> separate the LLVM core from, e.g., Clang, because LLVM could export >> its targets and Clang could just import them via find_package. The >> rest of Clang's CMakeLists.txt files shouldn't have to change. > > At some point on the past, I had a patch for doing that without the need > of find_package. It removed the requirement of putting clang under the > LLVM source tree. It wasn't committed because I wanted to improve some > aesthetics and becuase I didn't perceived too much enthusiasm about that > feature. You'll likely get more enthusiasm as Clang and LLVM get bigger and bigger. The Xcode project for Clang+LLVM is *huge*, and things will get much more interesting when we get a CMake'ified lldb (which depends on Clang+LLVM). We have a lot more subprojects than we had even a year ago, and they're not small. > The issue here is that this patch goes against the main goal of the > CMake build as I implemented it: simple maintenance. As configure&&make > is the most used system by the developers, the CMake build will > inevitably go out of sync with the actual state of the source. Recently, this hasn't been much of a problem. LLVM developers have gotten accustomed to updating CMakeLists.txt files, and we now have buildbots that use the CMake build system (on Windows), so I find myself having to fix CMakeLists.txt files far less often than even a few months ago. Plus, there are at least several Clang developers that use the CMake build system on a daily basis. When problems crop up, they get fixed fast. > So > easying the job of fixing it is paramount. On the case of a removed or > added source file the fix is easy, something anyone can do without > having a cmake build hence doable for those who use conf&&make. Not so > for a change on a library dependency: figuring out what's happening > *and* the optimal point for fixing the broken dependency is not so easy > and may require quite a few tentative builds. Furthermore, unnecessary > dependencis will accumulate either due to failures at reflecting the > optimal dependencies (i.e. putting the dependency on libraries A and B > when it should go to C) or due to dependencies which are no longer > required. This goes against your goal of having an easy way of seeing > the project structure. Mistakes can creep in anywhere, and when we find them, we'll fix them. Automatic checking (as Rafael mentioned) would certainly help, but a little common sense goes a long way toward keeping things consistent, and I believe that LLVM developers are careful enough that these issues won't turn into serious problems. > There are other more subtle cases of possible > brokenness, such as removed libraries that are forgotten on the list of > dependencies: the problem would only be visible if you do "make clean > all". The buildbots do a "make clean all" every hour or so; we'd catch such an error quickly. > Overall, my opinion is that removing automatic library dependencies will > create more broken builds and will increase the time required for fixing > the breakage. It will be seen as a problem too if at some point someone > proposes to switch to CMake and ditch configure&&make (just remember how > much fuss was about explicitly adding and removing source files to the > build.) I think that the best thing we can do for our users is to > provide a reliable build, even if that requires renouncing to some nifty > features. At least until CMake is adopted as the official LLVM build. Let's say that we adopt CMake as the official LLVM build system tomorrow. Would you still want implicit dependencies, or would you then favor explicit dependencies? - Doug From wendling at apple.com Sat Sep 11 19:22:45 2010 From: wendling at apple.com (Bill Wendling) Date: Sat, 11 Sep 2010 17:22:45 -0700 Subject: [llvm-commits] [llvm] r113670 - in /llvm/trunk: include/llvm/Target/TargetInstrInfo.h lib/CodeGen/PeepholeOptimizer.cpp lib/Target/ARM/ARMBaseInstrInfo.cpp lib/Target/ARM/ARMBaseInstrInfo.h In-Reply-To: <2da5ae35-a8e5-4373-8732-c9073b95b598@q2g2000vbk.googlegroups.com> References: <20100911001350.9B7AE2A6C12C@llvm.org> <2da5ae35-a8e5-4373-8732-c9073b95b598@q2g2000vbk.googlegroups.com> Message-ID: <5292DDBE-195D-4E8E-8462-7650E7C3E649@apple.com> On Sep 11, 2010, at 12:49 AM, Gabor Greif wrote: > Bill, > > you might be interested in my dabbling attempts > with http://llvm.org/bugs/show_bug.cgi?id=8125 > The x86 peephole already manages to eliminate > the test after the 'and', It would be interesting > to see whether ARM does too. > Btw., my commit is not really restricted to 'and', > any operation that sets the zero flag will do. > > A.t.m. (before your changes) I got: > LBB0_1: @ %tailrecurse > @ =>This Inner Loop Header: > Depth=1 > ldr lr, [r2, #-4] > and r4, lr, #3 > tst lr, #3 > beq LBB0_4 > I saw your patch go through. As with your other code, I don't understand it fully. :) It's certainly an interesting optimization. But I think that we would still need the peephole optimizer for ARM (and PPC?). X86's instructions either always set the EFLAGS register or not. A lot of ARM instructions may set CSPR, but they don't have to. And it appears that that decision needs to wait until after instruction selection... -bw From ofv at wanadoo.es Sat Sep 11 19:29:29 2010 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Sun, 12 Sep 2010 02:29:29 +0200 Subject: [llvm-commits] [PATCH][CMake] Removing LLVMLibDeps.cmake and exporting libraries for CMake clients. References: <87vd6fejb9.fsf@telefonica.net> <470F86A9-0C61-47BF-B12B-1556310BFA55@apple.com> <87occ3di97.fsf@telefonica.net> Message-ID: <87k4mrdct2.fsf@telefonica.net> ?scar Fuentes writes: [snip] >> Michael has addressed the problems that cropped up. Do we know of any >> other problems that need to be addressed? > > I haven't looked at the patch in detail, but my experience says that > issues will appear. This is not my main concern, though. Just tried the build on Linux/AMD64, and it fails with this: Linking CXX executable ../../bin/llvm-mc ../../lib/libLLVMPIC16AsmPrinter.a(PIC16AsmPrinter.cpp.o): In function `llvm::PIC16AsmPrinter::doFinalization(llvm::Module&)': PIC16AsmPrinter.cpp:(.text+0x12a2): undefined reference to `llvm::PIC16DbgInfo::EndModule(llvm::Module&)' ../../lib/libLLVMPIC16AsmPrinter.a(PIC16AsmPrinter.cpp.o): In function `llvm::PIC16AsmPrinter::doInitialization(llvm::Module&)': PIC16AsmPrinter.cpp:(.text+0x1f86): undefined reference to `llvm::PIC16DbgInfo::BeginModule(llvm::Module&)' ../../lib/libLLVMPIC16AsmPrinter.a(PIC16AsmPrinter.cpp.o): In function `llvm::PIC16AsmPrinter::runOnMachineFunction(llvm::MachineFunction&)': PIC16AsmPrinter.cpp:(.text+0x3be4): undefined reference to `llvm::PIC16DbgInfo::BeginFunction(llvm::MachineFunction const&)' PIC16AsmPrinter.cpp:(.text+0x3f3e): undefined reference to `llvm::PIC16DbgInfo::ChangeDebugLoc(llvm::MachineFunction const&, llvm::DebugLoc const&, bool)' PIC16AsmPrinter.cpp:(.text+0x3fcf): undefined reference to `llvm::PIC16DbgInfo::EndFunction(llvm::MachineFunction const&)' collect2: ld returned 1 exit status make[2]: *** [bin/llvm-mc] Error 1 make[1]: *** [tools/llvm-mc/CMakeFiles/llvm-mc.dir/all] Error 2 make: *** [all] Error 2 As Michael reported that the build worked for him on Linux yesterday, it would be *very* interesting to analyze this failure. It can be illustrative. From ofv at wanadoo.es Sat Sep 11 21:27:15 2010 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar?= Fuentes) Date: Sun, 12 Sep 2010 04:27:15 +0200 Subject: [llvm-commits] [PATCH][CMake] Removing LLVMLibDeps.cmake and exporting libraries for CMake clients. In-Reply-To: <2FED81DC-D4AD-47A6-9863-8ACB3C2B5586@apple.com> (Douglas Gregor's message of "Sat, 11 Sep 2010 17:11:05 -0700") References: <87vd6fejb9.fsf@telefonica.net> <470F86A9-0C61-47BF-B12B-1556310BFA55@apple.com> <87occ3di97.fsf@telefonica.net> <2FED81DC-D4AD-47A6-9863-8ACB3C2B5586@apple.com> Message-ID: <878w37d7cs.fsf@telefonica.net> Douglas Gregor writes: > If you want the whole picture, it's slightly better to have one large > list of dependencies. That said, text is a horrible format for such a > task, and it's far more likely that someone wanted to look at the > whole picture would actually want a picture, e.g., as generated by > GraphViz. Again, extracting GraphViz data or XML describing dependencies from CMake is unaffected by the automatic dependency system. > I do have a few issues with putting all of the dependencies in a single file: > > 1) People forget about it when they make changes. LLVM > developers have gotten fairly good at updating CMakeLists.txt > when they change the corresponding makefile (finally!), because > they live alongside the Makefiles. This other file off in an > apparently-unrelated subdirectory gets forgotten. > > 2) Most of the time, we want to reason about dependencies > locally ("I added this feature, and now my library depends > on..."), and a single file makes that harder. If explicitly keeping library dependencies are so good, why do you keep using the llvm-config script on the configure&&make build? Why llvm-config was introduced on the first place? > 3) It's unclear how a "single file" works for multiple > projects. For example, LLVMLibDeps didn't have Clang's > dependencies, because Clang is in a different repository. Should > Clang have its own ClangLibDeps? Should they all be merged > together? We actually had a mix of LLVMLibDeps dependencies and > per-CMakeLists.txt dependencies. Since I implemented the CMake build on Clang, I lost touch with it. Hence can't comment. But I don't see how the existence of LLVMLibDeps is an inconvenience for Clang. [snip] >> CPack works fine with the automatic library dependency system. Please >> note that the automatic system ends using target_link_libraries anyways, >> so putting it explicitly on the corresponding CMakeLists.txt makes no >> difference for tools that require its existente. > > I'm specifically referring to dependencies in component-based > installers, which are separate from those dependencies and can be at a > higher level of granularity (e.g., dependencies between groups of > libraries in the graphical installer). Again, this is independent of where you put target_link_libraries, on each CMakeLists.txt or on some .cmake script. > My understanding of CMake's export feature is that it helps with this, > too; you can use CMake variables to push find_package toward, for > example, a build tree of LLVM in your project that depends on LLVM. In any case, this shall be documented on docs/CMake.html, with examples for the case of multiple installs. I wouldn't never approve the change until it includes updates to the documentation. >> For the average user, I don't think that find_package offers significant >> advantages over the method documented in >> >> http://www.llvm.org/docs/CMake.html#embedding > > I think the advantage is familiarity; we'd fit better into the general > CMake ecosystem if we follow their conventions. I'm more concerned about fitting into the LLVM ecosystem :-) [snip] > Mistakes can creep in anywhere, and when we find them, we'll fix them. The point about the automatic system is that it avoids mistakes and makes fixes unnecessary. [snip] > Let's say that we adopt CMake as the official LLVM build system > tomorrow. Would you still want implicit dependencies, or would you > then favor explicit dependencies? I think that automatically updated library dependencies ("implicit" is not the right word, as they are very explicitly stated on LLVMLibDeps.cmake) saves work and are more accurate than manually mantained ones. If you want to stay on touch with the structure of the project, you look at LLVMLibDeps.cmake or ask CMake for a XML or GraphViz file that describes it. Doug, if you are so convinced about the virtues of manually maintained library dependencies for LLVM, go ahead, keep the change on the repo. After all, if I'm right about my concerns it doesn't mean complete disaster. But I'll like to be sure that you are not basing your decision on false premises and that you are aware of the social and workload implications. I know you are committed to a high quality CMake build and possibly can devote more energy than me to that cause. So I'm willing to silence my opposition and pass the responsibility of driving the evolution of the CMake build to you and others who have their own ideas and want to see them materialized. I hate to stop people from doing things and think that I can't always keep others from making mistakes. Not to mention that sometimes it is me who is mistaken ;-) From echristo at apple.com Sat Sep 11 22:26:36 2010 From: echristo at apple.com (Eric Christopher) Date: Sun, 12 Sep 2010 03:26:36 -0000 Subject: [llvm-commits] [llvm-gcc-4.2] r113710 - in /llvm-gcc-4.2/trunk/gcc: config/arm/llvm-arm-target.h config/arm/llvm-arm.cpp llvm-abi-default.cpp llvm-abi.h llvm-convert.cpp llvm-types.cpp Message-ID: <20100912032637.086E92A6C12C@llvm.org> Author: echristo Date: Sat Sep 11 22:26:36 2010 New Revision: 113710 URL: http://llvm.org/viewvc/llvm-project?rev=113710&view=rev Log: Revert 113694 in an attempt to fix the buildbots. Modified: llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp llvm-gcc-4.2/trunk/gcc/llvm-abi.h llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp llvm-gcc-4.2/trunk/gcc/llvm-types.cpp Modified: llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h?rev=113710&r1=113709&r2=113710&view=diff ============================================================================== --- llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h (original) +++ llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h Sat Sep 11 22:26:36 2010 @@ -55,15 +55,6 @@ #define LLVM_SHOULD_PASS_AGGREGATE_IN_MIXED_REGS(T, TY, CC, E) \ llvm_arm_should_pass_aggregate_in_mixed_regs((T), (TY), (CC), (E)) -struct DefaultABIClient; -extern bool -llvm_arm_try_pass_aggregate_custom(tree, std::vector&, - CallingConv::ID&, - struct DefaultABIClient*); - -#define LLVM_TRY_PASS_AGGREGATE_CUSTOM(T, E, CC, C) \ - llvm_arm_try_pass_aggregate_custom((T), (E), (CC), (C)) - extern bool llvm_arm_aggregate_partially_passed_in_regs(std::vector&, std::vector&, Modified: llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp?rev=113710&r1=113709&r2=113710&view=diff ============================================================================== --- llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp (original) +++ llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp Sat Sep 11 22:26:36 2010 @@ -2557,91 +2557,6 @@ } } -static unsigned count_num_words(std::vector &ScalarElts) { - unsigned NumWords = 0; - for (unsigned i = 0, e = ScalarElts.size(); i != e; ++i) { - const Type *Ty = ScalarElts[i]; - if (Ty->isPointerTy()) { - NumWords++; - } else if (Ty->isIntegerTy()) { - const unsigned TypeSize = Ty->getPrimitiveSizeInBits(); - const unsigned NumWordsForType = (TypeSize + 31) / 32; - - NumWords += NumWordsForType; - } else { - assert (0 && "Unexpected type."); - } - } - return NumWords; -} - -// This function is used only on AAPCS. The difference from the generic -// handling of arguments is that arguments larger than 32 bits are split -// and padding arguments are added as necessary for alignment. This makes -// the IL a bit more explicit about how arguments are handled. -extern bool -llvm_arm_try_pass_aggregate_custom(tree type, - std::vector& ScalarElts, - CallingConv::ID& CC, - struct DefaultABIClient* C) { - if (CC != CallingConv::ARM_AAPCS && CC != CallingConv::C) - return false; - - if (CC == CallingConv::C && !TARGET_AAPCS_BASED) - return false; - - if (TARGET_HARD_FLOAT_ABI) - return false; - const Type *Ty = ConvertType(type); - if (Ty->isPointerTy()) - return false; - - const unsigned Size = TREE_INT_CST_LOW(TYPE_SIZE(type))/8; - const unsigned Alignment = TYPE_ALIGN(type)/8; - const unsigned NumWords = count_num_words(ScalarElts); - const bool AddPad = Alignment >= 8 && (NumWords % 2); - - // First, build a type that will be bitcast to the original one and - // from where elements will be extracted. - std::vector Elts; - const Type* Int32Ty = Type::getInt32Ty(getGlobalContext()); - const unsigned NumRegularArgs = Size / 4; - for (unsigned i = 0; i < NumRegularArgs; ++i) { - Elts.push_back(Int32Ty); - } - const unsigned RestSize = Size % 4; - const llvm::Type *RestType = NULL; - if (RestSize> 2) { - RestType = Type::getInt32Ty(getGlobalContext()); - } else if (RestSize > 1) { - RestType = Type::getInt16Ty(getGlobalContext()); - } else if (RestSize > 0) { - RestType = Type::getInt8Ty(getGlobalContext()); - } - if (RestType) - Elts.push_back(RestType); - const StructType *STy = StructType::get(getGlobalContext(), Elts, false); - - if (AddPad) { - ScalarElts.push_back(Int32Ty); - C->HandlePad(Int32Ty); - } - - for (unsigned i = 0; i < NumRegularArgs; ++i) { - C->EnterField(i, STy); - C->HandleScalarArgument(Int32Ty, 0); - ScalarElts.push_back(Int32Ty); - C->ExitField(); - } - if (RestType) { - C->EnterField(NumRegularArgs, STy); - C->HandleScalarArgument(RestType, 0, RestSize); - ScalarElts.push_back(RestType); - C->ExitField(); - } - return true; -} - // Target hook for llvm-abi.h. It returns true if an aggregate of the // specified type should be passed in a number of registers of mixed types. // It also returns a vector of types that correspond to the registers used Modified: llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp?rev=113710&r1=113709&r2=113710&view=diff ============================================================================== --- llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp (original) +++ llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp Sat Sep 11 22:26:36 2010 @@ -8,8 +8,7 @@ /// return type. It potentially breaks down the argument and invokes methods /// on the client that indicate how its pieces should be handled. This /// handles things like returning structures via hidden parameters. -void DefaultABI::HandleReturnType(tree type, tree fn, bool isBuiltin, - std::vector &ScalarElts) { +void DefaultABI::HandleReturnType(tree type, tree fn, bool isBuiltin) { unsigned Offset = 0; const Type *Ty = ConvertType(type); if (Ty->isVectorTy()) { @@ -53,9 +52,7 @@ // FIXME: should return the hidden first argument for some targets // (e.g. ELF i386). - const PointerType *PTy = Ty->getPointerTo(); - C.HandleAggregateShadowResult(PTy, false); - ScalarElts.push_back(PTy); + C.HandleAggregateShadowResult(Ty->getPointerTo(), false); } } Modified: llvm-gcc-4.2/trunk/gcc/llvm-abi.h URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-abi.h?rev=113710&r1=113709&r2=113710&view=diff ============================================================================== --- llvm-gcc-4.2/trunk/gcc/llvm-abi.h (original) +++ llvm-gcc-4.2/trunk/gcc/llvm-abi.h Sat Sep 11 22:26:36 2010 @@ -396,8 +396,7 @@ /// return type. It potentially breaks down the argument and invokes methods /// on the client that indicate how its pieces should be handled. This /// handles things like returning structures via hidden parameters. - void HandleReturnType(tree type, tree fn, bool isBuiltin, - std::vector &ScalarElts); + void HandleReturnType(tree type, tree fn, bool isBuiltin); /// HandleArgument - This is invoked by the target-independent code for each /// argument type passed into the function. It potentially breaks down the Modified: llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp?rev=113710&r1=113709&r2=113710&view=diff ============================================================================== --- llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp (original) +++ llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp Sat Sep 11 22:26:36 2010 @@ -673,19 +673,17 @@ FunctionPrologArgumentConversion Client(FnDecl, AI, Builder, CallingConv); DefaultABI ABIConverter(Client); - // Scalar arguments processed so far. - std::vector ScalarArgs; - // Handle the DECL_RESULT. ABIConverter.HandleReturnType(TREE_TYPE(TREE_TYPE(FnDecl)), FnDecl, - DECL_BUILT_IN(FnDecl), - ScalarArgs); + DECL_BUILT_IN(FnDecl)); // Remember this for use by FinishFunctionBody. ReturnOffset = Client.Offset; // Prepend the static chain (if any) to the list of arguments. tree Args = static_chain ? static_chain : DECL_ARGUMENTS(FnDecl); + // Scalar arguments processed so far. + std::vector ScalarArgs; while (Args) { const char *Name = "unnamed_arg"; if (DECL_NAME(Args)) Name = IDENTIFIER_POINTER(DECL_NAME(Args)); @@ -3014,17 +3012,16 @@ DefaultABI ABIConverter(Client); // Handle the result, including struct returns. - std::vector ScalarArgs; ABIConverter.HandleReturnType(TREE_TYPE(exp), fndecl ? fndecl : exp, - fndecl ? DECL_BUILT_IN(fndecl) : false, - ScalarArgs); + fndecl ? DECL_BUILT_IN(fndecl) : false); // Pass the static chain, if any, as the first parameter. if (TREE_OPERAND(exp, 2)) CallOperands.push_back(Emit(TREE_OPERAND(exp, 2), 0)); // Loop over the arguments, expanding them and adding them to the op list. + std::vector ScalarArgs; for (tree arg = TREE_OPERAND(exp, 1); arg; arg = TREE_CHAIN(arg)) { tree type = TREE_TYPE(TREE_VALUE(arg)); const Type *ArgTy = ConvertType(type); Modified: llvm-gcc-4.2/trunk/gcc/llvm-types.cpp URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-types.cpp?rev=113710&r1=113709&r2=113710&view=diff ============================================================================== --- llvm-gcc-4.2/trunk/gcc/llvm-types.cpp (original) +++ llvm-gcc-4.2/trunk/gcc/llvm-types.cpp Sat Sep 11 22:26:36 2010 @@ -1082,10 +1082,8 @@ TARGET_ADJUST_LLVM_CC(CallingConv, type); #endif - std::vector ScalarArgs; // Builtins are always prototyped, so this isn't one. - ABIConverter.HandleReturnType(ReturnType, current_function_decl, false, - ScalarArgs); + ABIConverter.HandleReturnType(ReturnType, current_function_decl, false); SmallVector Attrs; @@ -1112,6 +1110,7 @@ Attrs.push_back(AttributeWithIndex::get(ArgTys.size(), Attribute::StructRet)); + std::vector ScalarArgs; if (static_chain) { // Pass the static chain as the first parameter. ABIConverter.HandleArgument(TREE_TYPE(static_chain), ScalarArgs); @@ -1153,10 +1152,8 @@ TARGET_ADJUST_LLVM_CC(CallingConv, type); #endif - std::vector ScalarArgs; ABIConverter.HandleReturnType(TREE_TYPE(type), current_function_decl, - decl ? DECL_BUILT_IN(decl) : false, - ScalarArgs); + decl ? DECL_BUILT_IN(decl) : false); // Compute attributes for return type (and function attributes). SmallVector Attrs; @@ -1221,6 +1218,7 @@ Attrs.push_back(AttributeWithIndex::get(ArgTypes.size(), Attribute::StructRet | Attribute::NoAlias)); + std::vector ScalarArgs; if (static_chain) { // Pass the static chain as the first parameter. ABIConverter.HandleArgument(TREE_TYPE(static_chain), ScalarArgs); From bigcheesegs at gmail.com Sat Sep 11 22:47:31 2010 From: bigcheesegs at gmail.com (Michael J. Spencer) Date: Sun, 12 Sep 2010 03:47:31 -0000 Subject: [llvm-commits] [llvm] r113712 - /llvm/trunk/lib/Target/PIC16/AsmPrinter/CMakeLists.txt Message-ID: <20100912034731.DF5E02A6C12C@llvm.org> Author: mspencer Date: Sat Sep 11 22:47:31 2010 New Revision: 113712 URL: http://llvm.org/viewvc/llvm-project?rev=113712&view=rev Log: CMake: Fix mingw32 build. Modified: llvm/trunk/lib/Target/PIC16/AsmPrinter/CMakeLists.txt Modified: llvm/trunk/lib/Target/PIC16/AsmPrinter/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PIC16/AsmPrinter/CMakeLists.txt?rev=113712&r1=113711&r2=113712&view=diff ============================================================================== --- llvm/trunk/lib/Target/PIC16/AsmPrinter/CMakeLists.txt (original) +++ llvm/trunk/lib/Target/PIC16/AsmPrinter/CMakeLists.txt Sat Sep 11 22:47:31 2010 @@ -6,4 +6,9 @@ add_llvm_library(LLVMPIC16AsmPrinter PIC16AsmPrinter.cpp ) + +target_link_libraries(LLVMPIC16AsmPrinter + LLVMPIC16CodeGen + ) + add_dependencies(LLVMPIC16AsmPrinter PIC16CodeGenTable_gen) From echristo at apple.com Sun Sep 12 01:09:23 2010 From: echristo at apple.com (Eric Christopher) Date: Sun, 12 Sep 2010 06:09:23 -0000 Subject: [llvm-commits] [llvm] r113720 - in /llvm/trunk: lib/Transforms/InstCombine/InstCombineAndOrXor.cpp test/CodeGen/ARM/fast-isel.ll test/Transforms/InstCombine/and-or-inversion.ll test/Transforms/InstCombine/cast.ll test/Transforms/InstCombine/or.ll test/Transforms/InstCombine/xor2.ll Message-ID: <20100912060923.4A1722A6C12C@llvm.org> Author: echristo Date: Sun Sep 12 01:09:23 2010 New Revision: 113720 URL: http://llvm.org/viewvc/llvm-project?rev=113720&view=rev Log: Revert 113679, it was causing an infinite loop in a testcase that I've sent on to Owen. Removed: llvm/trunk/test/Transforms/InstCombine/and-or-inversion.ll Modified: llvm/trunk/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp llvm/trunk/test/CodeGen/ARM/fast-isel.ll llvm/trunk/test/Transforms/InstCombine/cast.ll llvm/trunk/test/Transforms/InstCombine/or.ll llvm/trunk/test/Transforms/InstCombine/xor2.ll Modified: llvm/trunk/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp?rev=113720&r1=113719&r2=113720&view=diff ============================================================================== --- llvm/trunk/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp (original) +++ llvm/trunk/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp Sun Sep 12 01:09:23 2010 @@ -207,26 +207,12 @@ } break; case Instruction::Or: - if (Op->hasOneUse()){ - if (Together != OpRHS) { - // (X | C1) & C2 --> (X | (C1&C2)) & C2 - Value *Or = Builder->CreateOr(X, Together); - Or->takeName(Op); - return BinaryOperator::CreateAnd(Or, AndRHS); - } - - ConstantInt *TogetherCI = dyn_cast(Together); - if (TogetherCI && !TogetherCI->isZero()){ - // (X | C1) & C2 --> (X & (C2^(C1&C2))) | C1 - // NOTE: This reduces the number of bits set in the & mask, which - // can expose opportunities for store narrowing. - Together = ConstantExpr::getXor(AndRHS, Together); - Value *And = Builder->CreateAnd(X, Together); - And->takeName(Op); - return BinaryOperator::CreateOr(And, OpRHS); - } + if (Op->hasOneUse() && Together != OpRHS) { + // (X | C1) & C2 --> (X | (C1&C2)) & C2 + Value *Or = Builder->CreateOr(X, Together); + Or->takeName(Op); + return BinaryOperator::CreateAnd(Or, AndRHS); } - break; case Instruction::Add: if (Op->hasOneUse()) { @@ -1957,17 +1943,6 @@ } } - // Note: If we've gotten to the point of visiting the outer OR, then the - // inner one couldn't be simplified. If it was a constant, then it won't - // be simplified by a later pass either, so we try swapping the inner/outer - // ORs in the hopes that we'll be able to simplify it this way. - // (X|C) | V --> (X|V) | C - if (Op0->hasOneUse() && match(Op0, m_Or(m_Value(A), m_ConstantInt(C1)))) { - Value *Inner = Builder->CreateOr(Op0, Op1); - Inner->takeName(Op0); - return BinaryOperator::CreateOr(Inner, C1); - } - return Changed ? &I : 0; } Modified: llvm/trunk/test/CodeGen/ARM/fast-isel.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/ARM/fast-isel.ll?rev=113720&r1=113719&r2=113720&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/ARM/fast-isel.ll (original) +++ llvm/trunk/test/CodeGen/ARM/fast-isel.ll Sun Sep 12 01:09:23 2010 @@ -15,6 +15,22 @@ ret i32 %add } +define float @fp_ops(float %a, float %b) nounwind { +entry: + %a.addr = alloca float, align 4 + %b.addr = alloca float, align 4 + store float %a, float* %a.addr + store float %b, float* %b.addr + %tmp = load float* %a.addr + %tmp1 = load float* %b.addr + %mul = fmul float %tmp, %tmp1 + %tmp2 = load float* %b.addr + %tmp3 = load float* %a.addr + %mul2 = fmul float %tmp2, %tmp3 + %add = fadd float %mul, %mul2 + ret float %mul +} + define i32* @foo(i32* %p, i32* %q, i32** %z) nounwind { entry: %r = load i32* %p Removed: llvm/trunk/test/Transforms/InstCombine/and-or-inversion.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/and-or-inversion.ll?rev=113719&view=auto ============================================================================== --- llvm/trunk/test/Transforms/InstCombine/and-or-inversion.ll (original) +++ llvm/trunk/test/Transforms/InstCombine/and-or-inversion.ll (removed) @@ -1,13 +0,0 @@ -; RUN: opt -S -instcombine < %s | FileCheck %s -; - -; CHECK: @func -define i32 @func(i32 %a) nounwind ssp align 2 { -entry: -; CHECK: and i32 %a, -256 - %0 = or i32 %a, 8 -; CHECK: or i32 %0, 8 - %1 = and i32 %0, -248 - ret i32 %1 -; CHECK: } -} Modified: llvm/trunk/test/Transforms/InstCombine/cast.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/cast.ll?rev=113720&r1=113719&r2=113720&view=diff ============================================================================== --- llvm/trunk/test/Transforms/InstCombine/cast.ll (original) +++ llvm/trunk/test/Transforms/InstCombine/cast.ll Sun Sep 12 01:09:23 2010 @@ -437,8 +437,8 @@ ret i64 %E ; CHECK: @test47 ; CHECK-NEXT: %B = sext i8 %A to i64 -; CHECK-NEXT: %C = and i64 %B, 4294967253 -; CHECK-NEXT: %E = or i64 %C, 42 +; CHECK-NEXT: %C = or i64 %B, 42 +; CHECK-NEXT: %E = and i64 %C, 4294967295 ; CHECK-NEXT: ret i64 %E } @@ -508,8 +508,8 @@ ret i32 %E ; CHECK: @test52 ; CHECK-NEXT: %B = trunc i64 %A to i32 -; CHECK-NEXT: %C = and i32 %B, 7224 -; CHECK-NEXT: %D = or i32 %C, 32962 +; CHECK-NEXT: %C = or i32 %B, 32962 +; CHECK-NEXT: %D = and i32 %C, 40186 ; CHECK-NEXT: ret i32 %D } @@ -521,8 +521,8 @@ ret i64 %E ; CHECK: @test53 ; CHECK-NEXT: %B = zext i32 %A to i64 -; CHECK-NEXT: %C = and i64 %B, 7224 -; CHECK-NEXT: %D = or i64 %C, 32962 +; CHECK-NEXT: %C = or i64 %B, 32962 +; CHECK-NEXT: %D = and i64 %C, 40186 ; CHECK-NEXT: ret i64 %D } @@ -534,8 +534,8 @@ ret i32 %E ; CHECK: @test54 ; CHECK-NEXT: %B = trunc i64 %A to i32 -; CHECK-NEXT: %C = and i32 %B, 7224 -; CHECK-NEXT: %D = or i32 %C, -32574 +; CHECK-NEXT: %C = or i32 %B, -32574 +; CHECK-NEXT: %D = and i32 %C, -25350 ; CHECK-NEXT: ret i32 %D } @@ -547,8 +547,8 @@ ret i64 %E ; CHECK: @test55 ; CHECK-NEXT: %B = zext i32 %A to i64 -; CHECK-NEXT: %C = and i64 %B, 7224 -; CHECK-NEXT: %D = or i64 %C, -32574 +; CHECK-NEXT: %C = or i64 %B, -32574 +; CHECK-NEXT: %D = and i64 %C, -25350 ; CHECK-NEXT: ret i64 %D } @@ -584,8 +584,8 @@ ; CHECK: @test58 ; CHECK-NEXT: %C = lshr i64 %A, 8 -; CHECK-NEXT: %D = and i64 %C, 16777087 -; CHECK-NEXT: %E = or i64 %D, 128 +; CHECK-NEXT: %D = or i64 %C, 128 +; CHECK-NEXT: %E = and i64 %D, 16777215 ; CHECK-NEXT: ret i64 %E } Modified: llvm/trunk/test/Transforms/InstCombine/or.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/or.ll?rev=113720&r1=113719&r2=113720&view=diff ============================================================================== --- llvm/trunk/test/Transforms/InstCombine/or.ll (original) +++ llvm/trunk/test/Transforms/InstCombine/or.ll Sun Sep 12 01:09:23 2010 @@ -316,8 +316,8 @@ %E = or i32 %D, %C ret i32 %E ; CHECK: @test30 -; CHECK: %D = and i32 %A, -58312 -; CHECK: %E = or i32 %D, 32962 +; CHECK: %B = or i32 %A, 32962 +; CHECK: %E = and i32 %B, -25350 ; CHECK: ret i32 %E } @@ -332,8 +332,8 @@ %F = or i64 %D, %E ret i64 %F ; CHECK: @test31 -; CHECK-NEXT: %E1 = and i64 %A, 4294908984 -; CHECK-NEXT: %F = or i64 %E1, 32962 +; CHECK-NEXT: %bitfield = or i64 %A, 32962 +; CHECK-NEXT: %F = and i64 %bitfield, 4294941946 ; CHECK-NEXT: ret i64 %F } @@ -367,12 +367,3 @@ ; CHECK-NEXT: or i32 %X, %Y ; CHECK-NEXT: ret } - -define i32 @test35(i32 %a, i32 %b) { - %1 = or i32 %a, 1135 - %2 = or i32 %1, %b - ret i32 %2 - ; CHECK: @test35 - ; CHECK-NEXT: or i32 %a, %b - ; CHECK-NEXT: or i32 %1, 1135 -} Modified: llvm/trunk/test/Transforms/InstCombine/xor2.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/xor2.ll?rev=113720&r1=113719&r2=113720&view=diff ============================================================================== --- llvm/trunk/test/Transforms/InstCombine/xor2.ll (original) +++ llvm/trunk/test/Transforms/InstCombine/xor2.ll Sun Sep 12 01:09:23 2010 @@ -34,7 +34,7 @@ define i32 @test3(i32 %tmp1) { ; CHECK: @test3 ; CHECK-NEXT: and i32 %tmp1, 32 -; CHECK-NEXT: or i32 %ovm, 8 +; CHECK-NEXT: or i32 %tmp, 8 ; CHECK-NEXT: ret i32 %ovm = or i32 %tmp1, 145 %ov31 = and i32 %ovm, 177 From espindola at google.com Sun Sep 12 02:23:54 2010 From: espindola at google.com (Rafael Espindola) Date: Sun, 12 Sep 2010 03:23:54 -0400 Subject: [llvm-commits] [llvm-gcc-4.2] r113710 - in /llvm-gcc-4.2/trunk/gcc: config/arm/llvm-arm-target.h config/arm/llvm-arm.cpp llvm-abi-default.cpp llvm-abi.h llvm-convert.cpp llvm-types.cpp In-Reply-To: <20100912032637.086E92A6C12C@llvm.org> References: <20100912032637.086E92A6C12C@llvm.org> Message-ID: Thanks. Do you have a testcase? For some reason I got no email from the bots... On 11 September 2010 23:26, Eric Christopher wrote: > Author: echristo > Date: Sat Sep 11 22:26:36 2010 > New Revision: 113710 > > URL: http://llvm.org/viewvc/llvm-project?rev=113710&view=rev > Log: > Revert 113694 in an attempt to fix the buildbots. > > Modified: > ? ?llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h > ? ?llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp > ? ?llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp > ? ?llvm-gcc-4.2/trunk/gcc/llvm-abi.h > ? ?llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp > ? ?llvm-gcc-4.2/trunk/gcc/llvm-types.cpp > > Modified: llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h > URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h?rev=113710&r1=113709&r2=113710&view=diff > ============================================================================== > --- llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h (original) > +++ llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h Sat Sep 11 22:26:36 2010 > @@ -55,15 +55,6 @@ > ?#define LLVM_SHOULD_PASS_AGGREGATE_IN_MIXED_REGS(T, TY, CC, E) ? ?\ > ? ?llvm_arm_should_pass_aggregate_in_mixed_regs((T), (TY), (CC), (E)) > > -struct DefaultABIClient; > -extern bool > -llvm_arm_try_pass_aggregate_custom(tree, std::vector&, > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?CallingConv::ID&, > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct DefaultABIClient*); > - > -#define LLVM_TRY_PASS_AGGREGATE_CUSTOM(T, E, CC, C) ? ?\ > - ?llvm_arm_try_pass_aggregate_custom((T), (E), (CC), (C)) > - > ?extern > ?bool llvm_arm_aggregate_partially_passed_in_regs(std::vector&, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?std::vector&, > > Modified: llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp > URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp?rev=113710&r1=113709&r2=113710&view=diff > ============================================================================== > --- llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp (original) > +++ llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp Sat Sep 11 22:26:36 2010 > @@ -2557,91 +2557,6 @@ > ? } > ?} > > -static unsigned count_num_words(std::vector &ScalarElts) { > - ?unsigned NumWords = 0; > - ?for (unsigned i = 0, e = ScalarElts.size(); i != e; ++i) { > - ? ?const Type *Ty = ScalarElts[i]; > - ? ?if (Ty->isPointerTy()) { > - ? ? ?NumWords++; > - ? ?} else if (Ty->isIntegerTy()) { > - ? ? ?const unsigned TypeSize = Ty->getPrimitiveSizeInBits(); > - ? ? ?const unsigned NumWordsForType = (TypeSize + 31) / 32; > - > - ? ? ?NumWords += NumWordsForType; > - ? ?} else { > - ? ? ?assert (0 && "Unexpected type."); > - ? ?} > - ?} > - ?return NumWords; > -} > - > -// This function is used only on AAPCS. The difference from the generic > -// handling of arguments is that arguments larger than 32 bits are split > -// and padding arguments are added as necessary for alignment. This makes > -// the IL a bit more explicit about how arguments are handled. > -extern bool > -llvm_arm_try_pass_aggregate_custom(tree type, > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? std::vector& ScalarElts, > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?CallingConv::ID& CC, > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct DefaultABIClient* C) { > - ?if (CC != CallingConv::ARM_AAPCS && CC != CallingConv::C) > - ? ?return false; > - > - ?if (CC == CallingConv::C && !TARGET_AAPCS_BASED) > - ? ?return false; > - > - ?if (TARGET_HARD_FLOAT_ABI) > - ? ?return false; > - ?const Type *Ty = ConvertType(type); > - ?if (Ty->isPointerTy()) > - ? ?return false; > - > - ?const unsigned Size = TREE_INT_CST_LOW(TYPE_SIZE(type))/8; > - ?const unsigned Alignment = TYPE_ALIGN(type)/8; > - ?const unsigned NumWords = count_num_words(ScalarElts); > - ?const bool AddPad = Alignment >= 8 && (NumWords % 2); > - > - ?// First, build a type that will be bitcast to the original one and > - ?// from where elements will be extracted. > - ?std::vector Elts; > - ?const Type* Int32Ty = Type::getInt32Ty(getGlobalContext()); > - ?const unsigned NumRegularArgs = Size / 4; > - ?for (unsigned i = 0; i < NumRegularArgs; ++i) { > - ? ?Elts.push_back(Int32Ty); > - ?} > - ?const unsigned RestSize = Size % 4; > - ?const llvm::Type *RestType = NULL; > - ?if (RestSize> 2) { > - ? ?RestType = Type::getInt32Ty(getGlobalContext()); > - ?} else if (RestSize > 1) { > - ? ?RestType = Type::getInt16Ty(getGlobalContext()); > - ?} else if (RestSize > 0) { > - ? ?RestType = Type::getInt8Ty(getGlobalContext()); > - ?} > - ?if (RestType) > - ? ?Elts.push_back(RestType); > - ?const StructType *STy = StructType::get(getGlobalContext(), Elts, false); > - > - ?if (AddPad) { > - ? ?ScalarElts.push_back(Int32Ty); > - ? ?C->HandlePad(Int32Ty); > - ?} > - > - ?for (unsigned i = 0; i < NumRegularArgs; ++i) { > - ? ?C->EnterField(i, STy); > - ? ?C->HandleScalarArgument(Int32Ty, 0); > - ? ?ScalarElts.push_back(Int32Ty); > - ? ?C->ExitField(); > - ?} > - ?if (RestType) { > - ? ?C->EnterField(NumRegularArgs, STy); > - ? ?C->HandleScalarArgument(RestType, 0, RestSize); > - ? ?ScalarElts.push_back(RestType); > - ? ?C->ExitField(); > - ?} > - ?return true; > -} > - > ?// Target hook for llvm-abi.h. It returns true if an aggregate of the > ?// specified type should be passed in a number of registers of mixed types. > ?// It also returns a vector of types that correspond to the registers used > > Modified: llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp > URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp?rev=113710&r1=113709&r2=113710&view=diff > ============================================================================== > --- llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp (original) > +++ llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp Sat Sep 11 22:26:36 2010 > @@ -8,8 +8,7 @@ > ?/// return type. It potentially breaks down the argument and invokes methods > ?/// on the client that indicate how its pieces should be handled. ?This > ?/// handles things like returning structures via hidden parameters. > -void DefaultABI::HandleReturnType(tree type, tree fn, bool isBuiltin, > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?std::vector &ScalarElts) { > +void DefaultABI::HandleReturnType(tree type, tree fn, bool isBuiltin) { > ? unsigned Offset = 0; > ? const Type *Ty = ConvertType(type); > ? if (Ty->isVectorTy()) { > @@ -53,9 +52,7 @@ > > ? ? // FIXME: should return the hidden first argument for some targets > ? ? // (e.g. ELF i386). > - ? ?const PointerType *PTy = Ty->getPointerTo(); > - ? ?C.HandleAggregateShadowResult(PTy, false); > - ? ?ScalarElts.push_back(PTy); > + ? ?C.HandleAggregateShadowResult(Ty->getPointerTo(), false); > ? } > ?} > > > Modified: llvm-gcc-4.2/trunk/gcc/llvm-abi.h > URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-abi.h?rev=113710&r1=113709&r2=113710&view=diff > ============================================================================== > --- llvm-gcc-4.2/trunk/gcc/llvm-abi.h (original) > +++ llvm-gcc-4.2/trunk/gcc/llvm-abi.h Sat Sep 11 22:26:36 2010 > @@ -396,8 +396,7 @@ > ? /// return type. It potentially breaks down the argument and invokes methods > ? /// on the client that indicate how its pieces should be handled. ?This > ? /// handles things like returning structures via hidden parameters. > - ?void HandleReturnType(tree type, tree fn, bool isBuiltin, > - ? ? ? ? ? ? ? ? ? ? ? ?std::vector &ScalarElts); > + ?void HandleReturnType(tree type, tree fn, bool isBuiltin); > > ? /// HandleArgument - This is invoked by the target-independent code for each > ? /// argument type passed into the function. ?It potentially breaks down the > > Modified: llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp > URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp?rev=113710&r1=113709&r2=113710&view=diff > ============================================================================== > --- llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp (original) > +++ llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp Sat Sep 11 22:26:36 2010 > @@ -673,19 +673,17 @@ > ? FunctionPrologArgumentConversion Client(FnDecl, AI, Builder, CallingConv); > ? DefaultABI ABIConverter(Client); > > - ?// Scalar arguments processed so far. > - ?std::vector ScalarArgs; > - > ? // Handle the DECL_RESULT. > ? ABIConverter.HandleReturnType(TREE_TYPE(TREE_TYPE(FnDecl)), FnDecl, > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DECL_BUILT_IN(FnDecl), > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ScalarArgs); > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DECL_BUILT_IN(FnDecl)); > ? // Remember this for use by FinishFunctionBody. > ? ReturnOffset = Client.Offset; > > ? // Prepend the static chain (if any) to the list of arguments. > ? tree Args = static_chain ? static_chain : DECL_ARGUMENTS(FnDecl); > > + ?// Scalar arguments processed so far. > + ?std::vector ScalarArgs; > ? while (Args) { > ? ? const char *Name = "unnamed_arg"; > ? ? if (DECL_NAME(Args)) Name = IDENTIFIER_POINTER(DECL_NAME(Args)); > @@ -3014,17 +3012,16 @@ > ? DefaultABI ABIConverter(Client); > > ? // Handle the result, including struct returns. > - ?std::vector ScalarArgs; > ? ABIConverter.HandleReturnType(TREE_TYPE(exp), > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? fndecl ? fndecl : exp, > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?fndecl ? DECL_BUILT_IN(fndecl) : false, > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ScalarArgs); > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?fndecl ? DECL_BUILT_IN(fndecl) : false); > > ? // Pass the static chain, if any, as the first parameter. > ? if (TREE_OPERAND(exp, 2)) > ? ? CallOperands.push_back(Emit(TREE_OPERAND(exp, 2), 0)); > > ? // Loop over the arguments, expanding them and adding them to the op list. > + ?std::vector ScalarArgs; > ? for (tree arg = TREE_OPERAND(exp, 1); arg; arg = TREE_CHAIN(arg)) { > ? ? tree type = TREE_TYPE(TREE_VALUE(arg)); > ? ? const Type *ArgTy = ConvertType(type); > > Modified: llvm-gcc-4.2/trunk/gcc/llvm-types.cpp > URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-types.cpp?rev=113710&r1=113709&r2=113710&view=diff > ============================================================================== > --- llvm-gcc-4.2/trunk/gcc/llvm-types.cpp (original) > +++ llvm-gcc-4.2/trunk/gcc/llvm-types.cpp Sat Sep 11 22:26:36 2010 > @@ -1082,10 +1082,8 @@ > ? TARGET_ADJUST_LLVM_CC(CallingConv, type); > ?#endif > > - ?std::vector ScalarArgs; > ? // Builtins are always prototyped, so this isn't one. > - ?ABIConverter.HandleReturnType(ReturnType, current_function_decl, false, > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ScalarArgs); > + ?ABIConverter.HandleReturnType(ReturnType, current_function_decl, false); > > ? SmallVector Attrs; > > @@ -1112,6 +1110,7 @@ > ? ? Attrs.push_back(AttributeWithIndex::get(ArgTys.size(), > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Attribute::StructRet)); > > + ?std::vector ScalarArgs; > ? if (static_chain) { > ? ? // Pass the static chain as the first parameter. > ? ? ABIConverter.HandleArgument(TREE_TYPE(static_chain), ScalarArgs); > @@ -1153,10 +1152,8 @@ > ? TARGET_ADJUST_LLVM_CC(CallingConv, type); > ?#endif > > - ?std::vector ScalarArgs; > ? ABIConverter.HandleReturnType(TREE_TYPE(type), current_function_decl, > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?decl ? DECL_BUILT_IN(decl) : false, > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ScalarArgs); > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?decl ? DECL_BUILT_IN(decl) : false); > > ? // Compute attributes for return type (and function attributes). > ? SmallVector Attrs; > @@ -1221,6 +1218,7 @@ > ? ? Attrs.push_back(AttributeWithIndex::get(ArgTypes.size(), > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Attribute::StructRet | Attribute::NoAlias)); > > + ?std::vector ScalarArgs; > ? if (static_chain) { > ? ? // Pass the static chain as the first parameter. > ? ? ABIConverter.HandleArgument(TREE_TYPE(static_chain), ScalarArgs); > > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > -- Rafael ?vila de Esp?ndola From echristo at apple.com Sun Sep 12 02:25:45 2010 From: echristo at apple.com (Eric Christopher) Date: Sun, 12 Sep 2010 00:25:45 -0700 Subject: [llvm-commits] [llvm-gcc-4.2] r113710 - in /llvm-gcc-4.2/trunk/gcc: config/arm/llvm-arm-target.h config/arm/llvm-arm.cpp llvm-abi-default.cpp llvm-abi.h llvm-convert.cpp llvm-types.cpp In-Reply-To: References: <20100912032637.086E92A6C12C@llvm.org> Message-ID: <9F4852D2-A728-4171-83C3-E75229FE9D40@apple.com> On Sep 12, 2010, at 12:23 AM, Rafael Espindola wrote: > Thanks. Do you have a testcase? For some reason I got no email from the bots... I don't sorry, but the llvm-gcc darwin selfhost-rel bot was failing before I reverted it. Lots of crashes post-bootstrap. Can you bootstrap and then try using that compiler to compile llvm or run the testsuite on darwin? I think I saw it fail doing that. -eric From espindola at google.com Sun Sep 12 02:29:21 2010 From: espindola at google.com (Rafael Espindola) Date: Sun, 12 Sep 2010 03:29:21 -0400 Subject: [llvm-commits] [llvm-gcc-4.2] r113710 - in /llvm-gcc-4.2/trunk/gcc: config/arm/llvm-arm-target.h config/arm/llvm-arm.cpp llvm-abi-default.cpp llvm-abi.h llvm-convert.cpp llvm-types.cpp In-Reply-To: <9F4852D2-A728-4171-83C3-E75229FE9D40@apple.com> References: <20100912032637.086E92A6C12C@llvm.org> <9F4852D2-A728-4171-83C3-E75229FE9D40@apple.com> Message-ID: On 12 September 2010 03:25, Eric Christopher wrote: > > On Sep 12, 2010, at 12:23 AM, Rafael Espindola wrote: > >> Thanks. Do you have a testcase? For some reason I got no email from the bots... > > I don't sorry, but the llvm-gcc darwin selfhost-rel bot was failing before I reverted it. ?Lots of crashes post-bootstrap. > > Can you bootstrap and then try using that compiler to compile llvm or run the testsuite on darwin? ?I think I saw it fail doing that. On Darwin X86_64? I will give it a try. Probably missed some use of ScalarElts. Sorry about that. > -eric Cheers, -- Rafael ?vila de Esp?ndola From echristo at apple.com Sun Sep 12 02:37:47 2010 From: echristo at apple.com (Eric Christopher) Date: Sun, 12 Sep 2010 00:37:47 -0700 Subject: [llvm-commits] [llvm-gcc-4.2] r113710 - in /llvm-gcc-4.2/trunk/gcc: config/arm/llvm-arm-target.h config/arm/llvm-arm.cpp llvm-abi-default.cpp llvm-abi.h llvm-convert.cpp llvm-types.cpp In-Reply-To: References: <20100912032637.086E92A6C12C@llvm.org> <9F4852D2-A728-4171-83C3-E75229FE9D40@apple.com> Message-ID: <897DF0A4-0D7F-4B77-AE9E-24617C509C25@apple.com> On Sep 12, 2010, at 12:29 AM, Rafael Espindola wrote: > On 12 September 2010 03:25, Eric Christopher wrote: >> >> On Sep 12, 2010, at 12:23 AM, Rafael Espindola wrote: >> >>> Thanks. Do you have a testcase? For some reason I got no email from the bots... >> >> I don't sorry, but the llvm-gcc darwin selfhost-rel bot was failing before I reverted it. Lots of crashes post-bootstrap. >> >> Can you bootstrap and then try using that compiler to compile llvm or run the testsuite on darwin? I think I saw it fail doing that. > > On Darwin X86_64? I will give it a try. Probably missed some use of > ScalarElts. Sorry about that. No problem. It happens. I only noticed because another tester of mine died a horrible death trying to build stuff :) -eric From rafael.espindola at gmail.com Sun Sep 12 04:00:41 2010 From: rafael.espindola at gmail.com (Rafael Espindola) Date: Sun, 12 Sep 2010 09:00:41 -0000 Subject: [llvm-commits] [llvm-gcc-4.2] r113726 - in /llvm-gcc-4.2/trunk/gcc: config/arm/llvm-arm-target.h config/arm/llvm-arm.cpp config/i386/llvm-i386-target.h config/i386/llvm-i386.cpp llvm-abi-default.cpp llvm-abi.h llvm-convert.cpp llvm-types.cpp Message-ID: <20100912090041.C93C12A6C12C@llvm.org> Author: rafael Date: Sun Sep 12 04:00:41 2010 New Revision: 113726 URL: http://llvm.org/viewvc/llvm-project?rev=113726&view=rev Log: Fixed version of 113694. The problem with the original one is that it would cause double accounting of sret parameters. Original message: Lower ARM function signatures a bit more. I implemented only AAPCS since that is what I can test. With this patch we convert struct foo {double a; int b;}; void f(int, struct foo); void g(int a, double b, int c) { struct foo x = {b, c}; f(a, x); } into ------------------------------------------------------ define void @g(i32 %a.0, i32, i32 %b.0, i32 %b.1, i32 %c.0) nounwind optsize { entry: tail call void @f(i32 %a.0, i32 undef, i32 %b.0, i32 %b.1, i32 %c.0, i32 0) nounwind ret void } declare void @f(i32, i32, i32, i32, i32, i32) ---------------------------------------------------- instead of --------------------------------------------------- define void @g(i32 %a, double %b, i32 %c) nounwind optsize { entry: %tmp11 = bitcast double %b to i64 %tmp5 = zext i32 %c to i64 tail call void @f(i32 %a, i64 %tmp11, i64 %tmp5) nounwind ret void } declare void @f(i32, i64, i64) -------------------------------------------------- The IL for ------------------------------------------ double foo(double X, double Y) { return X+Y; } ----------------------------------------- now shows that the arguments being passed in the integer registres: ---------------------------------------------------------------------- define double @foo(i32 %X.0, i32 %X.1, i32 %Y.0, i32 %Y.1) nounwind readnone optsize { entry: %tmp17 = zext i32 %X.0 to i64 %tmp12 = zext i32 %X.1 to i64 %tmp13 = shl i64 %tmp12, 32 %ins15 = or i64 %tmp13, %tmp17 %tmp6 = zext i32 %Y.0 to i64 %tmp3 = zext i32 %Y.1 to i64 %tmp4 = shl i64 %tmp3, 32 %ins = or i64 %tmp4, %tmp6 %tmp10 = bitcast i64 %ins15 to double %tmp2 = bitcast i64 %ins to double %0 = fadd double %tmp10, %tmp2 ret double %0 } --------------------------------------------------------------------- And the produces assembly is the same as before: ---------------------------------------------------------------- foo: vmov d0, r2, r3 vmov d1, r0, r1 vadd.f64 d0, d1, d0 vmov r0, r1, d0 bx lr ---------------------------------------------------------------- Modified: llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386-target.h llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp llvm-gcc-4.2/trunk/gcc/llvm-abi.h llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp llvm-gcc-4.2/trunk/gcc/llvm-types.cpp Modified: llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h?rev=113726&r1=113725&r2=113726&view=diff ============================================================================== --- llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h (original) +++ llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm-target.h Sun Sep 12 04:00:41 2010 @@ -55,13 +55,22 @@ #define LLVM_SHOULD_PASS_AGGREGATE_IN_MIXED_REGS(T, TY, CC, E) \ llvm_arm_should_pass_aggregate_in_mixed_regs((T), (TY), (CC), (E)) +struct DefaultABIClient; +extern bool +llvm_arm_try_pass_aggregate_custom(tree, std::vector&, + CallingConv::ID&, + struct DefaultABIClient*); + +#define LLVM_TRY_PASS_AGGREGATE_CUSTOM(T, E, CC, C) \ + llvm_arm_try_pass_aggregate_custom((T), (E), (CC), (C)) + extern bool llvm_arm_aggregate_partially_passed_in_regs(std::vector&, std::vector&, - bool, CallingConv::ID&); + CallingConv::ID&); -#define LLVM_AGGREGATE_PARTIALLY_PASSED_IN_REGS(E, SE, ISR, CC) \ - llvm_arm_aggregate_partially_passed_in_regs((E), (SE), (ISR), (CC)) +#define LLVM_AGGREGATE_PARTIALLY_PASSED_IN_REGS(E, SE, CC) \ + llvm_arm_aggregate_partially_passed_in_regs((E), (SE), (CC)) extern const Type *llvm_arm_aggr_type_for_struct_return(tree type, CallingConv::ID &CC); Modified: llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp?rev=113726&r1=113725&r2=113726&view=diff ============================================================================== --- llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp (original) +++ llvm-gcc-4.2/trunk/gcc/config/arm/llvm-arm.cpp Sun Sep 12 04:00:41 2010 @@ -2557,6 +2557,91 @@ } } +static unsigned count_num_words(std::vector &ScalarElts) { + unsigned NumWords = 0; + for (unsigned i = 0, e = ScalarElts.size(); i != e; ++i) { + const Type *Ty = ScalarElts[i]; + if (Ty->isPointerTy()) { + NumWords++; + } else if (Ty->isIntegerTy()) { + const unsigned TypeSize = Ty->getPrimitiveSizeInBits(); + const unsigned NumWordsForType = (TypeSize + 31) / 32; + + NumWords += NumWordsForType; + } else { + assert (0 && "Unexpected type."); + } + } + return NumWords; +} + +// This function is used only on AAPCS. The difference from the generic +// handling of arguments is that arguments larger than 32 bits are split +// and padding arguments are added as necessary for alignment. This makes +// the IL a bit more explicit about how arguments are handled. +extern bool +llvm_arm_try_pass_aggregate_custom(tree type, + std::vector& ScalarElts, + CallingConv::ID& CC, + struct DefaultABIClient* C) { + if (CC != CallingConv::ARM_AAPCS && CC != CallingConv::C) + return false; + + if (CC == CallingConv::C && !TARGET_AAPCS_BASED) + return false; + + if (TARGET_HARD_FLOAT_ABI) + return false; + const Type *Ty = ConvertType(type); + if (Ty->isPointerTy()) + return false; + + const unsigned Size = TREE_INT_CST_LOW(TYPE_SIZE(type))/8; + const unsigned Alignment = TYPE_ALIGN(type)/8; + const unsigned NumWords = count_num_words(ScalarElts); + const bool AddPad = Alignment >= 8 && (NumWords % 2); + + // First, build a type that will be bitcast to the original one and + // from where elements will be extracted. + std::vector Elts; + const Type* Int32Ty = Type::getInt32Ty(getGlobalContext()); + const unsigned NumRegularArgs = Size / 4; + for (unsigned i = 0; i < NumRegularArgs; ++i) { + Elts.push_back(Int32Ty); + } + const unsigned RestSize = Size % 4; + const llvm::Type *RestType = NULL; + if (RestSize> 2) { + RestType = Type::getInt32Ty(getGlobalContext()); + } else if (RestSize > 1) { + RestType = Type::getInt16Ty(getGlobalContext()); + } else if (RestSize > 0) { + RestType = Type::getInt8Ty(getGlobalContext()); + } + if (RestType) + Elts.push_back(RestType); + const StructType *STy = StructType::get(getGlobalContext(), Elts, false); + + if (AddPad) { + ScalarElts.push_back(Int32Ty); + C->HandlePad(Int32Ty); + } + + for (unsigned i = 0; i < NumRegularArgs; ++i) { + C->EnterField(i, STy); + C->HandleScalarArgument(Int32Ty, 0); + ScalarElts.push_back(Int32Ty); + C->ExitField(); + } + if (RestType) { + C->EnterField(NumRegularArgs, STy); + C->HandleScalarArgument(RestType, 0, RestSize); + ScalarElts.push_back(RestType); + C->ExitField(); + } + return true; +} + // Target hook for llvm-abi.h. It returns true if an aggregate of the // specified type should be passed in a number of registers of mixed types. // It also returns a vector of types that correspond to the registers used @@ -2658,7 +2743,6 @@ bool llvm_arm_aggregate_partially_passed_in_regs(std::vector &Elts, std::vector &ScalarElts, - bool isShadowReturn, CallingConv::ID &CC) { // Homogeneous aggregates are an AAPCS-VFP feature. if ((CC != CallingConv::ARM_AAPCS_VFP) || Modified: llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386-target.h URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386-target.h?rev=113726&r1=113725&r2=113726&view=diff ============================================================================== --- llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386-target.h (original) +++ llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386-target.h Sun Sep 12 04:00:41 2010 @@ -219,12 +219,11 @@ extern bool llvm_x86_64_aggregate_partially_passed_in_regs(std::vector&, - std::vector&, - bool); + std::vector&); -#define LLVM_AGGREGATE_PARTIALLY_PASSED_IN_REGS(E, SE, ISR, CC) \ +#define LLVM_AGGREGATE_PARTIALLY_PASSED_IN_REGS(E, SE, CC) \ (TARGET_64BIT ? \ - llvm_x86_64_aggregate_partially_passed_in_regs((E), (SE), (ISR)) : \ + llvm_x86_64_aggregate_partially_passed_in_regs((E), (SE)) : \ false) #endif /* LLVM_ABI_H */ Modified: llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp?rev=113726&r1=113725&r2=113726&view=diff ============================================================================== --- llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp (original) +++ llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp Sun Sep 12 04:00:41 2010 @@ -869,8 +869,7 @@ be passed in memory. */ bool llvm_x86_64_aggregate_partially_passed_in_regs(std::vector &Elts, - std::vector &ScalarElts, - bool isShadowReturn) { + std::vector &ScalarElts) { // Counting number of GPRs and XMMs used so far. According to AMD64 ABI // document: "If there are no registers available for any eightbyte of an // argument, the whole argument is passed on the stack." X86-64 uses 6 @@ -879,7 +878,7 @@ // both parts will be in memory. // FIXME: This is a temporary solution. To be removed when llvm has first // class aggregate values. - unsigned NumGPRs = isShadowReturn ? 1 : 0; + unsigned NumGPRs = 0; unsigned NumXMMs = 0; count_num_registers_uses(ScalarElts, NumGPRs, NumXMMs); Modified: llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp?rev=113726&r1=113725&r2=113726&view=diff ============================================================================== --- llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp (original) +++ llvm-gcc-4.2/trunk/gcc/llvm-abi-default.cpp Sun Sep 12 04:00:41 2010 @@ -8,7 +8,8 @@ /// return type. It potentially breaks down the argument and invokes methods /// on the client that indicate how its pieces should be handled. This /// handles things like returning structures via hidden parameters. -void DefaultABI::HandleReturnType(tree type, tree fn, bool isBuiltin) { +void DefaultABI::HandleReturnType(tree type, tree fn, bool isBuiltin, + std::vector &ScalarElts) { unsigned Offset = 0; const Type *Ty = ConvertType(type); if (Ty->isVectorTy()) { @@ -52,7 +53,9 @@ // FIXME: should return the hidden first argument for some targets // (e.g. ELF i386). - C.HandleAggregateShadowResult(Ty->getPointerTo(), false); + const PointerType *PTy = Ty->getPointerTo(); + C.HandleAggregateShadowResult(PTy, false); + ScalarElts.push_back(PTy); } } @@ -104,7 +107,6 @@ C.getCallingConv(), Elts)) { if (!LLVM_AGGREGATE_PARTIALLY_PASSED_IN_REGS(Elts, ScalarElts, - C.isShadowReturn(), C.getCallingConv())) PassInMixedRegisters(Ty, Elts, ScalarElts); else { Modified: llvm-gcc-4.2/trunk/gcc/llvm-abi.h URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-abi.h?rev=113726&r1=113725&r2=113726&view=diff ============================================================================== --- llvm-gcc-4.2/trunk/gcc/llvm-abi.h (original) +++ llvm-gcc-4.2/trunk/gcc/llvm-abi.h Sun Sep 12 04:00:41 2010 @@ -302,7 +302,7 @@ // the aggregate. Note, this routine should return false if none of the needed // registers are available. #ifndef LLVM_AGGREGATE_PARTIALLY_PASSED_IN_REGS -#define LLVM_AGGREGATE_PARTIALLY_PASSED_IN_REGS(E, SE, ISR, CC) \ +#define LLVM_AGGREGATE_PARTIALLY_PASSED_IN_REGS(E, SE, CC) \ false #endif @@ -396,7 +396,8 @@ /// return type. It potentially breaks down the argument and invokes methods /// on the client that indicate how its pieces should be handled. This /// handles things like returning structures via hidden parameters. - void HandleReturnType(tree type, tree fn, bool isBuiltin); + void HandleReturnType(tree type, tree fn, bool isBuiltin, + std::vector &ScalarElts); /// HandleArgument - This is invoked by the target-independent code for each /// argument type passed into the function. It potentially breaks down the Modified: llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp?rev=113726&r1=113725&r2=113726&view=diff ============================================================================== --- llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp (original) +++ llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp Sun Sep 12 04:00:41 2010 @@ -436,13 +436,13 @@ // passed in memory byval. static bool isPassedByVal(tree type, const Type *Ty, std::vector &ScalarArgs, - bool isShadowRet, CallingConv::ID &CC) { + CallingConv::ID &CC) { if (LLVM_SHOULD_PASS_AGGREGATE_USING_BYVAL_ATTR(type, Ty)) return true; std::vector Args; if (LLVM_SHOULD_PASS_AGGREGATE_IN_MIXED_REGS(type, Ty, CC, Args) && - LLVM_AGGREGATE_PARTIALLY_PASSED_IN_REGS(Args, ScalarArgs, isShadowRet, + LLVM_AGGREGATE_PARTIALLY_PASSED_IN_REGS(Args, ScalarArgs, CC)) // We want to pass the whole aggregate in registers but only some of the // registers are available. @@ -673,17 +673,19 @@ FunctionPrologArgumentConversion Client(FnDecl, AI, Builder, CallingConv); DefaultABI ABIConverter(Client); + // Scalar arguments processed so far. + std::vector ScalarArgs; + // Handle the DECL_RESULT. ABIConverter.HandleReturnType(TREE_TYPE(TREE_TYPE(FnDecl)), FnDecl, - DECL_BUILT_IN(FnDecl)); + DECL_BUILT_IN(FnDecl), + ScalarArgs); // Remember this for use by FinishFunctionBody. ReturnOffset = Client.Offset; // Prepend the static chain (if any) to the list of arguments. tree Args = static_chain ? static_chain : DECL_ARGUMENTS(FnDecl); - // Scalar arguments processed so far. - std::vector ScalarArgs; while (Args) { const char *Name = "unnamed_arg"; if (DECL_NAME(Args)) Name = IDENTIFIER_POINTER(DECL_NAME(Args)); @@ -696,7 +698,7 @@ !LLVM_BYVAL_ALIGNMENT_TOO_SMALL(TREE_TYPE(Args))) || (!ArgTy->isSingleValueType() && isPassedByVal(TREE_TYPE(Args), ArgTy, ScalarArgs, - Client.isShadowReturn(), CallingConv) && + CallingConv) && !LLVM_BYVAL_ALIGNMENT_TOO_SMALL(TREE_TYPE(Args)))) { // If the value is passed by 'invisible reference' or 'byval reference', // the l-value for the argument IS the argument itself. But for byval @@ -3012,16 +3014,17 @@ DefaultABI ABIConverter(Client); // Handle the result, including struct returns. + std::vector ScalarArgs; ABIConverter.HandleReturnType(TREE_TYPE(exp), fndecl ? fndecl : exp, - fndecl ? DECL_BUILT_IN(fndecl) : false); + fndecl ? DECL_BUILT_IN(fndecl) : false, + ScalarArgs); // Pass the static chain, if any, as the first parameter. if (TREE_OPERAND(exp, 2)) CallOperands.push_back(Emit(TREE_OPERAND(exp, 2), 0)); // Loop over the arguments, expanding them and adding them to the op list. - std::vector ScalarArgs; for (tree arg = TREE_OPERAND(exp, 1); arg; arg = TREE_CHAIN(arg)) { tree type = TREE_TYPE(TREE_VALUE(arg)); const Type *ArgTy = ConvertType(type); Modified: llvm-gcc-4.2/trunk/gcc/llvm-types.cpp URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-types.cpp?rev=113726&r1=113725&r2=113726&view=diff ============================================================================== --- llvm-gcc-4.2/trunk/gcc/llvm-types.cpp (original) +++ llvm-gcc-4.2/trunk/gcc/llvm-types.cpp Sun Sep 12 04:00:41 2010 @@ -1082,8 +1082,10 @@ TARGET_ADJUST_LLVM_CC(CallingConv, type); #endif + std::vector ScalarArgs; // Builtins are always prototyped, so this isn't one. - ABIConverter.HandleReturnType(ReturnType, current_function_decl, false); + ABIConverter.HandleReturnType(ReturnType, current_function_decl, false, + ScalarArgs); SmallVector Attrs; @@ -1110,7 +1112,6 @@ Attrs.push_back(AttributeWithIndex::get(ArgTys.size(), Attribute::StructRet)); - std::vector ScalarArgs; if (static_chain) { // Pass the static chain as the first parameter. ABIConverter.HandleArgument(TREE_TYPE(static_chain), ScalarArgs); @@ -1152,8 +1153,10 @@ TARGET_ADJUST_LLVM_CC(CallingConv, type); #endif + std::vector ScalarArgs; ABIConverter.HandleReturnType(TREE_TYPE(type), current_function_decl, - decl ? DECL_BUILT_IN(decl) : false); + decl ? DECL_BUILT_IN(decl) : false, + ScalarArgs); // Compute attributes for return type (and function attributes). SmallVector Attrs; @@ -1218,7 +1221,6 @@ Attrs.push_back(AttributeWithIndex::get(ArgTypes.size(), Attribute::StructRet | Attribute::NoAlias)); - std::vector ScalarArgs; if (static_chain) { // Pass the static chain as the first parameter. ABIConverter.HandleArgument(TREE_TYPE(static_chain), ScalarArgs); From bigcheesegs at gmail.com Sun Sep 12 13:32:57 2010 From: bigcheesegs at gmail.com (Michael J. Spencer) Date: Sun, 12 Sep 2010 18:32:57 -0000 Subject: [llvm-commits] [llvm] r113727 - in /llvm/trunk/lib/Target: MSP430/TargetInfo/CMakeLists.txt PIC16/TargetInfo/CMakeLists.txt XCore/TargetInfo/CMakeLists.txt Message-ID: <20100912183257.F06DE2A6C12C@llvm.org> Author: mspencer Date: Sun Sep 12 13:32:57 2010 New Revision: 113727 URL: http://llvm.org/viewvc/llvm-project?rev=113727&view=rev Log: CMake: Fix MSVS build. Although I don't know why this didn't break other build systems... This problem is unrelated to the recent dependency tracking change. It seems like noone noticed the problem because I don't think anyone compiles any target other than X86 on windows. Modified: llvm/trunk/lib/Target/MSP430/TargetInfo/CMakeLists.txt llvm/trunk/lib/Target/PIC16/TargetInfo/CMakeLists.txt llvm/trunk/lib/Target/XCore/TargetInfo/CMakeLists.txt Modified: llvm/trunk/lib/Target/MSP430/TargetInfo/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/MSP430/TargetInfo/CMakeLists.txt?rev=113727&r1=113726&r2=113727&view=diff ============================================================================== --- llvm/trunk/lib/Target/MSP430/TargetInfo/CMakeLists.txt (original) +++ llvm/trunk/lib/Target/MSP430/TargetInfo/CMakeLists.txt Sun Sep 12 13:32:57 2010 @@ -4,4 +4,4 @@ MSP430TargetInfo.cpp ) -add_dependencies(LLVMMSP430Info MSP430Table_gen) +add_dependencies(LLVMMSP430Info MSP430CodeGenTable_gen) Modified: llvm/trunk/lib/Target/PIC16/TargetInfo/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PIC16/TargetInfo/CMakeLists.txt?rev=113727&r1=113726&r2=113727&view=diff ============================================================================== --- llvm/trunk/lib/Target/PIC16/TargetInfo/CMakeLists.txt (original) +++ llvm/trunk/lib/Target/PIC16/TargetInfo/CMakeLists.txt Sun Sep 12 13:32:57 2010 @@ -4,4 +4,4 @@ PIC16TargetInfo.cpp ) -add_dependencies(LLVMPIC16Info PIC16Table_gen) +add_dependencies(LLVMPIC16Info PIC16CodeGenTable_gen) Modified: llvm/trunk/lib/Target/XCore/TargetInfo/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/XCore/TargetInfo/CMakeLists.txt?rev=113727&r1=113726&r2=113727&view=diff ============================================================================== --- llvm/trunk/lib/Target/XCore/TargetInfo/CMakeLists.txt (original) +++ llvm/trunk/lib/Target/XCore/TargetInfo/CMakeLists.txt Sun Sep 12 13:32:57 2010 @@ -4,4 +4,4 @@ XCoreTargetInfo.cpp ) -add_dependencies(LLVMXCoreInfo XCoreTable_gen) +add_dependencies(LLVMXCoreInfo XCoreCodeGenTable_gen) From dalej at apple.com Sun Sep 12 17:36:13 2010 From: dalej at apple.com (Dale Johannesen) Date: Sun, 12 Sep 2010 22:36:13 -0000 Subject: [llvm-commits] [llvm] r113728 - /llvm/trunk/include/llvm/Type.h Message-ID: <20100912223613.584EB2A6C12C@llvm.org> Author: johannes Date: Sun Sep 12 17:36:13 2010 New Revision: 113728 URL: http://llvm.org/viewvc/llvm-project?rev=113728&view=rev Log: Fix comment typo. Modified: llvm/trunk/include/llvm/Type.h Modified: llvm/trunk/include/llvm/Type.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Type.h?rev=113728&r1=113727&r2=113728&view=diff ============================================================================== --- llvm/trunk/include/llvm/Type.h (original) +++ llvm/trunk/include/llvm/Type.h Sun Sep 12 17:36:13 2010 @@ -213,7 +213,7 @@ bool isFloatingPointTy() const { return ID == FloatTyID || ID == DoubleTyID || ID == X86_FP80TyID || ID == FP128TyID || ID == PPC_FP128TyID; } - /// isPPC_FP128Ty - Return true if this is X86 MMX. + /// isX86_MMXTy - Return true if this is X86 MMX. bool isX86_MMXTy() const { return ID == X86_MMXTyID; } /// isFPOrFPVectorTy - Return true if this is a FP type or a vector of FP.