From clattner at apple.com Mon Sep 22 00:03:05 2008 From: clattner at apple.com (Chris Lattner) Date: Sun, 21 Sep 2008 22:03:05 -0700 Subject: [llvm-commits] [llvm] r56341 - in /llvm/trunk: include/llvm/ include/llvm/Transforms/ lib/Transforms/IPO/ test/Analysis/GlobalsModRef/ test/Transforms/AddReadAttrs/ In-Reply-To: <200809190817.m8J8H6I8010267@zion.cs.uiuc.edu> References: <200809190817.m8J8H6I8010267@zion.cs.uiuc.edu> Message-ID: On Sep 19, 2008, at 1:17 AM, Duncan Sands wrote: > Author: baldrick > Date: Fri Sep 19 03:17:05 2008 > New Revision: 56341 > > URL: http://llvm.org/viewvc/llvm-project?rev=56341&view=rev > Log: > Add a new pass AddReadAttrs which works out which functions > can get the readnone/readonly attributes, and gives them it. > The plan is to remove markmodref (which did the same thing > by querying GlobalsModRef) and delete the analogous > functionality from GlobalsModRef. Ok. Here are some thoughts: CallGraph &CG = getAnalysis(); // Check if any of the functions in the SCC read or write memory. // If they write memory then just give up. ... This pass can only do something if the SCC is not already readnone. Does it make sense to do an initial check to see if the function is already readnone? Since it doesn't have to be a perfect check, how about something like: if (SCC.size() == 1 && SCC[0]->getFunction() && SCC[0]->getFunction()->doesNotAccessMemory()) return false; // already readnone Alternatively, maybe this should be handled by the 'already perfect' case you already have. // Definitions with weak linkage may be overridden at linktime with // something that writes memory, so treat them like declarations. if (F->isDeclaration() || F->hasWeakLinkage()) { This should also handle linkonce linkage. // Ignore calls to functions in the same SCC. if (CS.getInstruction() && std::find(SCC.begin(), SCC.end(), CG[CS.getCalledFunction()]) != SCC.end()) continue; This will be really slow for large SCCs. I think that some apps (like 176.gcc) have scc's with hundreds of nodes in them. Instead of using std::find, please dump the contents of the SCC into a SmallPtrSet at the start of the function, and query that instead. if (II->mayWriteToMemory()) return false; Please add a comment: "If this may write to memory, then we can't set either readnone or readonly, just give up." or something like that. Otherwise, the pass looks very nice Duncan! -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20080921/2b52bfed/attachment.html From clattner at apple.com Mon Sep 22 00:04:23 2008 From: clattner at apple.com (Chris Lattner) Date: Sun, 21 Sep 2008 22:04:23 -0700 Subject: [llvm-commits] [llvm] r56342 - in /llvm/trunk: include/llvm/LinkAllPasses.h include/llvm/Transforms/Scalar.h lib/Transforms/Scalar/MarkModRef.cpp test/Analysis/GlobalsModRef/2008-09-03-WrongRecords.ll win32/Transforms/Transforms.vcproj In-Reply-To: <200809190823.m8J8Nic6010477@zion.cs.uiuc.edu> References: <200809190823.m8J8Nic6010477@zion.cs.uiuc.edu> Message-ID: On Sep 19, 2008, at 1:23 AM, Duncan Sands wrote: > Author: baldrick > Date: Fri Sep 19 03:23:44 2008 > New Revision: 56342 > > URL: http://llvm.org/viewvc/llvm-project?rev=56342&view=rev > Log: > Remove the MarkModRef pass (use AddReadAttrs instead). > Unfortunately this means removing one regression test > of GlobalsModRef because I couldn't work out how to > perform it without MarkModRef. What is the issue? Also, why doesn't your AddReadAttrs pass use AliasAnalysis? -Chris From kremenek at apple.com Mon Sep 22 00:10:52 2008 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 22 Sep 2008 05:10:52 -0000 Subject: [llvm-commits] [llvm] r56428 - /llvm/tags/checker/checker-95/ Message-ID: <200809220510.m8M5Aqx9027237@zion.cs.uiuc.edu> Author: kremenek Date: Mon Sep 22 00:10:51 2008 New Revision: 56428 URL: http://llvm.org/viewvc/llvm-project?rev=56428&view=rev Log: Tagging checker-95. Added: llvm/tags/checker/checker-95/ - copied from r56427, llvm/trunk/ From clattner at apple.com Mon Sep 22 01:02:45 2008 From: clattner at apple.com (Chris Lattner) Date: Sun, 21 Sep 2008 23:02:45 -0700 Subject: [llvm-commits] [llvm] r55696 - in /llvm/trunk: lib/Analysis/IPA/GlobalsModRef.cpp test/Analysis/GlobalsModRef/2008-09-03-Mutual.ll test/Analysis/GlobalsModRef/2008-09-03-ReadGlobals.ll test/Analysis/GlobalsModRef/2008-09-03-ReadOnly.ll In-Reply-To: <200809031255.m83CtiI8031031@zion.cs.uiuc.edu> References: <200809031255.m83CtiI8031031@zion.cs.uiuc.edu> Message-ID: <4FC0A26E-21F6-4375-BD62-7B84CE946A4E@apple.com> On Sep 3, 2008, at 5:55 AM, Duncan Sands wrote: > URL: http://llvm.org/viewvc/llvm-project?rev=55696&view=rev > Log: > Cleanup GlobalsModRef a bit. When analysing the > callgraph, when one member of a SCC calls another > then the analysis would drop to mod-ref because > there is (usually) no function info for the callee > yet; fix this. Teach the analysis about function > attributes, in particular the readonly attribute > (which requires being careful about globals). Hey Duncan, Very nice. Do you have a specific interest/goal for GlobalsModRef, or is this just something you've notice that we do more poorly than we could? Better alias analysis helps everything, so it's great to see progress in this area! You've made a bunch of improvements to GlobalsModRef now and in the past, so I'm just going to go through and re-review it completely if that's ok with you. Well I guess it doesn't matter if it's ok or not, because I just did it. :) If you don't want to tackle something, let me know and I can add it to my queue. struct VISIBILITY_HIDDEN FunctionRecord { /// GlobalInfo - Maintain mod/ref info for all of the globals without /// addresses taken that are read or written (transitively) by this /// function. std::map GlobalInfo; /// MayReadAnyGlobal - May read global variables, but it is not known which. bool MayReadAnyGlobal; ... /// FunctionEffect - Capture whether or not this function reads or writes to /// ANY memory. If not, we can do a lot of aggressive analysis on it. unsigned FunctionEffect; Please keep the instance variables in the class together by moving getInfoForGlobal down, preferably after the ctor. Also, can you shrink FunctionEffect to a 'char'? That will reduce the size of FunctionRecord by a word, packing it next to the bool. As far as efficiency goes, GlobalInfo is mysterious: it is really horrible as a std::map (one allocation per insertion) but making it a densemap wouldn't be any better (tons of fragmentation). I think the best thing would be to eliminate it from FunctionRecord, and add a single unified DenseMap to the pass: DenseMap, unsigned> PerFunctionGlobalMRInfo; This would work just fine for almost all uses and is the best of both worlds, the one problem would be the 'Incorporate callee's effects on globals into our info.' loop. A solution to this would be to keep around the "per global" mod ref info for just the callees of the current SCC. What do you think? class VISIBILITY_HIDDEN GlobalsModRef : public ModulePass, public AliasAnalysis { Could this be a CallGraphSCCPass now? NonAddressTakenGlobals/IndirectGlobals should really be SmallPtrSet's, and AllocsForIndirectGlobals should be a densemap. virtual ModRefBehavior getModRefBehavior(Function *F, CallSite CS, std::vector *Info) { if (FunctionRecord *FR = getFunctionInfo(F)) { if (FR->FunctionEffect == 0) return DoesNotAccessMemory; else if ((FR->FunctionEffect & Mod) == 0) return OnlyReadsMemory; } return AliasAnalysis::getModRefBehavior(F, CS, Info); } Just because we think the function is readonly doesn't mean that a smarter analysis couldn't find that it is readnone. How about: else if ((FR->FunctionEffect & Mod) == 0) return AliasAnalysis::getModRefBehavior(F, CS, Info) & OnlyReadsMemory; ? /// getUnderlyingObject - This traverses the use chain to figure out what object /// the specified value points to. If the value points to, or is derived from, /// a global object, return it. static Value *getUnderlyingObject(Value *V) { I think this is an exact dupe of Value::stripPointerCasts now: getUnderlyingObject(V) == V->stripPointerCasts(); If it needs to stay for some reason, then this statement is not needed: // If we are at some type of object... return it. if (GlobalValue *GV = dyn_cast(V)) return GV; /// AnalyzeGlobals - Scan through the users of all of the internal /// GlobalValue's in the program. If none of them have their "address taken" "If none of them" -> "If any of them" for (Module::global_iterator I = M.global_begin(), E = M.global_end(); I != E; ++I) if (I->hasInternalLinkage()) { How about: if (!I->hasInternalLinkage()) continue; bool GlobalsModRef::AnalyzeUsesOfPointer(Value *V, .. } else if (CallInst *CI = dyn_cast(*UI)) { // Make sure that this is just the function being called, not that it is // passing into the function. for (unsigned i = 1, e = CI->getNumOperands(); i != e; ++i) if (CI->getOperand(i) == V) return true; it would be faster to check UI.getOperandNo() instead of looping, likewise for invoke. if (CE->getOpcode() == Instruction::GetElementPtr || CE->getOpcode() == Instruction::BitCast) { This code handles bitcast constant exprs but not bitcast instrs. :) Please add logic for bitcast instrs. if (F->getName() != "calloc") return false; // Not calloc. This should use F->isName("calloc") void GlobalsModRef::AnalyzeCallGraph(CallGraph &CG, Module &M) { ... if (F->isDeclaration()) { This needs a comment above it, something like: If there is a prototype in the SCC, then it is either an intrinsic, or an external function, which may do just about anything. We need to handle this separately from scanning the body of the function. // Try to get mod/ref behaviour from function attributes. if (F->doesNotAccessMemory()) { I don't think this should be checking function attributes for readonly/ readnone. Instead, it should chain to another alias analysis pass (which would end up at basicaa). basicaa would then be the one to check the attribute. for (CallGraphNode::iterator CI = SCC[i]->begin(), E = SCC[i]- >end(); CI != E && !KnowNothing; ++CI) Needs a comment: loop over all of the call graph edges out of this SCC node: i.e. all the called functions. if (Function *Callee = CI->second->getFunction()) { How about: Function *Callee = CI->second->getFunction(); if (Callee == 0) { KnowNothing = true; break; } ... // Can't say anything about it. However, if it is inside our SCC, // then nothing needs to be done. CallGraphNode *CalleeNode = CG[Callee]; if (std::find(SCC.begin(), SCC.end(), CalleeNode) == SCC.end()) KnowNothing = true; As before, please use SmallPtrSet instead of std::find. This is quadratic on large SCCs. // Scan the function bodies for explicit loads or stores. for (unsigned i = 0, e = SCC.size(); i != e && FunctionEffect != ModRef;++i) for (inst_iterator II = inst_begin(SCC[i]->getFunction()), E = inst_end(SCC[i]->getFunction()); II != E && FunctionEffect != ModRef; ++II) I think that this should Instruction::mayReadMemory and friends. It isn't handling the vaarg instruction, for example. Also, using these predicates would have handled the volatile case correctly automatically. GlobalsModRef::getModRefInfo(CallSite CS, Value *P, unsigned Size) { unsigned Known = ModRef; Shouldn't this take advantage of the FunctionEffect for the function as well, even if P isn't a pointer to a known global? -Chris From clattner at apple.com Mon Sep 22 01:09:11 2008 From: clattner at apple.com (Chris Lattner) Date: Sun, 21 Sep 2008 23:09:11 -0700 Subject: [llvm-commits] [llvm] r55409 - in /llvm/trunk: include/llvm/Support/DebugInfoBuilder.h lib/VMCore/DebugInfoBuilder.cpp In-Reply-To: <200808270651.m7R6pFf1026223@zion.cs.uiuc.edu> References: <200808270651.m7R6pFf1026223@zion.cs.uiuc.edu> Message-ID: <1EB8BE6B-6CC8-445E-B964-BF7DE2FA7637@apple.com> On Aug 26, 2008, at 11:51 PM, Evan Cheng wrote: > Author: evancheng > Date: Wed Aug 27 01:51:14 2008 > New Revision: 55409 > > URL: http://llvm.org/viewvc/llvm-project?rev=55409&view=rev > Log: > Add DebugInfoBuilder. Patch by Talin! Hi Talin, Your DebugInfoBuilder looks very nice. Have you had a chance to look at this proposal? http://nondot.org/sabre/LLVMNotes/EmbeddedMetadata.txt One piece of it (that is orthogonal from the rest) is the 'Debug Info Construction/Manipulation Helper Classes' section. I hadn't had a chance to dig into your debug info builder before writing that, but I now see that they are very very related. Between the two, I think that my proposal would be preferable because it would give better type info, and lend itself to clients that want to walk existing debug info, instead of just creating debug info. The other advantage of my proposal is that it would insulate clients from changes in the debug info representation: the debug classes could be based on GlobalVariables today, but the implementation could change under the covers to use MDNodes in the future with no or little changes to the clients. What are your thoughts? If we converge on this, I'd like to convert clang and llvm-gcc over to use the interface we finalize on (probably post 2.4). -Chris From evan.cheng at apple.com Mon Sep 22 01:09:48 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Sun, 21 Sep 2008 23:09:48 -0700 Subject: [llvm-commits] [llvm] r56310 - /llvm/trunk/lib/CodeGen/DeadMachineInstructionElim.cpp In-Reply-To: References: <200809181822.m8IIMW2k002887@zion.cs.uiuc.edu> <47A144A2-3B20-467D-8EAA-FB90DF12E434@apple.com> Message-ID: Local liveness hasn't been split out from livevariables. The plan is for DCE to track local liveness. Evan On Sep 21, 2008, at 8:27 PM, Chris Lattner wrote: > > On Sep 21, 2008, at 7:42 PM, Evan Cheng wrote: > >> This happens before livevariables. Remember we don't run LV at -O0. > > Not even local liveness? That would be enough to handle physregs. > > -Chris > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From clattner at apple.com Mon Sep 22 01:17:36 2008 From: clattner at apple.com (Chris Lattner) Date: Sun, 21 Sep 2008 23:17:36 -0700 Subject: [llvm-commits] [llvm] r56310 - /llvm/trunk/lib/CodeGen/DeadMachineInstructionElim.cpp In-Reply-To: References: <200809181822.m8IIMW2k002887@zion.cs.uiuc.edu> <47A144A2-3B20-467D-8EAA-FB90DF12E434@apple.com> Message-ID: <615BE1D9-7BFE-4828-B769-EB796B034932@apple.com> On Sep 21, 2008, at 11:09 PM, Evan Cheng wrote: > Local liveness hasn't been split out from livevariables. The plan is > for DCE to track local liveness. Ok! That would be great, considering it is already doing a backward scan. Would the register scavenger regtracker help with this? -Chris > > > Evan > > On Sep 21, 2008, at 8:27 PM, Chris Lattner wrote: > >> >> On Sep 21, 2008, at 7:42 PM, Evan Cheng wrote: >> >>> This happens before livevariables. Remember we don't run LV at -O0. >> >> Not even local liveness? That would be enough to handle physregs. >> >> -Chris >> >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From evan.cheng at apple.com Mon Sep 22 01:17:37 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Sun, 21 Sep 2008 23:17:37 -0700 Subject: [llvm-commits] [llvm] r56384 - in /llvm/trunk/lib/CodeGen: RegAllocLinearScan.cpp SimpleRegisterCoalescing.cpp In-Reply-To: <8D81D6DA-8289-49E2-B352-53C6C313FDA8@apple.com> References: <200809200203.m8K234YA013252@zion.cs.uiuc.edu> <4F71A860-E342-4A07-8211-0A59A1AA154D@apple.com> <8D81D6DA-8289-49E2-B352-53C6C313FDA8@apple.com> Message-ID: <33791BFC-A09D-43EB-B4D0-6582A9243EED@apple.com> On Sep 21, 2008, at 8:26 PM, Chris Lattner wrote: > On Sep 21, 2008, at 7:41 PM, Evan Cheng wrote: >>> If you model the early clobber def as starting one slot early, it >>> will >>> explicitly conflict with all inputs to the asm, and this can be >>> backed >>> out. >> >> While that's the correct approach, it breaks all kinds of assumptions >> in liveintervals and the coalescer. It will make the problem much >> more >> complicated. I don't think it's worth the effort. > > What sorts of assumptions? That use must be 1 cycle after instruction cycle, def must be 2 cycles after it. > > >> Besides, from uArch point of view, "early clobber" is totally bogus. >> It should really be "no read bypass". The correct way to model it >> would be to delay read by one cycle. > > It typically doesn't have anything to do with a micro architecture, it > has to do with the fact that an inline asm has multiple instructions. > For example if you had an inline asm with: > > "$out0 = inst1 $in1, 4 > $out1 = inst2 $in2, 142" > > Then you'd have to mark $out0 as being an early clobber, because it is > stored to before $in2 is read. Ewwww. Evan > > > -Chris > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From clattner at apple.com Mon Sep 22 01:19:20 2008 From: clattner at apple.com (Chris Lattner) Date: Sun, 21 Sep 2008 23:19:20 -0700 Subject: [llvm-commits] [llvm] r56384 - in /llvm/trunk/lib/CodeGen: RegAllocLinearScan.cpp SimpleRegisterCoalescing.cpp In-Reply-To: <33791BFC-A09D-43EB-B4D0-6582A9243EED@apple.com> References: <200809200203.m8K234YA013252@zion.cs.uiuc.edu> <4F71A860-E342-4A07-8211-0A59A1AA154D@apple.com> <8D81D6DA-8289-49E2-B352-53C6C313FDA8@apple.com> <33791BFC-A09D-43EB-B4D0-6582A9243EED@apple.com> Message-ID: On Sep 21, 2008, at 11:17 PM, Evan Cheng wrote: >>> While that's the correct approach, it breaks all kinds of >>> assumptions >>> in liveintervals and the coalescer. It will make the problem much >>> more >>> complicated. I don't think it's worth the effort. >> >> What sorts of assumptions? > > That use must be 1 cycle after instruction cycle, def must be 2 cycles > after it. What code makes this sort of assumption? It seems fragile. >> It typically doesn't have anything to do with a micro architecture, >> it >> has to do with the fact that an inline asm has multiple instructions. >> For example if you had an inline asm with: >> >> "$out0 = inst1 $in1, 4 >> $out1 = inst2 $in2, 142" >> >> Then you'd have to mark $out0 as being an early clobber, because it >> is >> stored to before $in2 is read. > > Ewwww. Eww what? You don't like asms with multiple instructions? Or you prefer CPUs that have instructions that would require this? ;-) -Chris From clattner at apple.com Mon Sep 22 01:26:17 2008 From: clattner at apple.com (Chris Lattner) Date: Sun, 21 Sep 2008 23:26:17 -0700 Subject: [llvm-commits] [llvm] r55969 - in /llvm/trunk: docs/LangRef.html include/llvm/Bitcode/LLVMBitCodes.h include/llvm/InstrTypes.h include/llvm/Instructions.h lib/AsmParser/llvmAsmParser.y lib/Bitcode/Reader/BitcodeReader.cpp lib/Bitcode/Writer/BitcodeWriter.cpp lib/VMCore/Verifier.cpp test/Assembler/vbool-cmp.ll test/Assembler/vector-select.ll In-Reply-To: <200809090102.m8912lLd009502@zion.cs.uiuc.edu> References: <200809090102.m8912lLd009502@zion.cs.uiuc.edu> Message-ID: On Sep 8, 2008, at 6:02 PM, Dan Gohman wrote: > Author: djg > Date: Mon Sep 8 20:02:47 2008 > New Revision: 55969 > > URL: http://llvm.org/viewvc/llvm-project?rev=55969&view=rev > Log: > Extend the vcmp/fcmp LLVM IR instructions to take vectors as arguments > and, if so, to return a vector of boolean as a result; Hi Dan and Preston, I thought the idea here was to change vicmp and vfcmp to have this behavior, not change icmp/fcmp to do this. The problem with changing icmp/fcmp is that you'll break a lot of assumptions throughout the optimizer that the result of icmp/fcmp is an i1, and the code to handle this has already been updated for v*cmp. > >> The FUNC_CODE_INST_VCMP thing is a little counter-intuitive. I guess >> it's necessary in order to remain compatible with exiting vector >> FUNC_CODE_INST_CMP usage though, right? > > Correct. Since FUNC_CODE_INST_CMP with vector arguments is used for > the > vfcmp and vicmp instructions, it was necessary to add > FUNC_CODE_INST_VCMP to support the vector forms of fcmp/icmp. It would > probably have made more sense in the bitcode reader/writer to switch > vicmp/vfcmp to use a newly defined bitcode operator, but I did not > because it seemed likely that it would break existing code. Is there any reason to keep around the old v*cmp behavior of returning a vector of integers? If not, please remove them (as soon as there are no regressions from doing this). I don't want to have two different vector compare implementations floating around. Also, LLVM 2.4 is coming up very soon now, would you be ok with deferring (and reverting) these changes until after 2.4 branches in a couple weeks? If you'd prefer to do development on a branch until then that would be fine of course. > Extend the select LLVM IR instruction to allow you to specify a result > type which is a vector of boolean, in which case the result will be an > element-wise selection instead of choosing one vector or the other; Cool, this is something we've needed for quite awhile. > = > = > = > = > = > = > = > = > ====================================================================== > --- llvm/trunk/include/llvm/Bitcode/LLVMBitCodes.h (original) > +++ llvm/trunk/include/llvm/Bitcode/LLVMBitCodes.h Mon Sep 8 > 20:02:47 2008 > @@ -205,7 +205,9 @@ > // FIXME: Remove GETRESULT in favor of EXTRACTVAL in LLVM 3.0 > FUNC_CODE_INST_GETRESULT = 25, // GETRESULT: [ty, opval, n] > FUNC_CODE_INST_EXTRACTVAL = 26, // EXTRACTVAL: [n x operands] > - FUNC_CODE_INST_INSERTVAL = 27 // INSERTVAL: [n x operands] > + FUNC_CODE_INST_INSERTVAL = 27, // INSERTVAL: [n x operands] > + // fcmp/icmp returning vector of Int1Ty, NOT for vicmp/vfcmp > + FUNC_CODE_INST_VCMP = 28 // VCMP: [opty, opval, > opval, pred] Ewww. I still think that vcmp should change into this behavior, if there is some reason why this would not work, please pick a better name than INST_VCMP for this! > = > = > = > = > = > = > = > = > ====================================================================== > --- llvm/trunk/include/llvm/InstrTypes.h (original) > +++ llvm/trunk/include/llvm/InstrTypes.h Mon Sep 8 20:02:47 2008 > @@ -18,6 +18,7 @@ > > #include "llvm/Instruction.h" > #include "llvm/OperandTraits.h" > +#include "llvm/DerivedTypes.h" Please move the method out of line, to avoid this #include. > @@ -732,6 +733,13 @@ > static inline bool classof(const Value *V) { > return isa(V) && classof(cast(V)); > } > + /// @brief Create a result type for fcmp/icmp (but not vicmp/vfcmp) > + static const Type* makeCmpResultType(const Type* opnd_type) { Instead of 'makeCmp...' please call this 'getVCmpResultType' or something like that. We use 'get' for uniqued objects like types. Assuming that you're going to eliminate vicmp/vfcmp, this should be removed and you should just change its methods. Okay, I can't review the rest of this patch without getting more closure on the direction we're going with the IR. I think that smooshing this into icmp/fcmp is a real mistake. We should change the old v[if]cmp instruction to return a vector of bool and leave icmp/ fcmp alone. What do you guys think? If you agree, please revert these patches for now. -Chris > = > = > = > = > = > = > = > = > ====================================================================== > --- llvm/trunk/include/llvm/Instructions.h (original) > +++ llvm/trunk/include/llvm/Instructions.h Mon Sep 8 20:02:47 2008 > @@ -621,7 +621,8 @@ > Value *RHS, ///< The right-hand-side of the expression > const std::string &NameStr = "", ///< Name of the instruction > Instruction *InsertBefore = 0 ///< Where to insert > - ) : CmpInst(Type::Int1Ty, Instruction::ICmp, pred, LHS, RHS, > NameStr, > + ) : CmpInst(makeCmpResultType(LHS->getType()), > + Instruction::ICmp, pred, LHS, RHS, NameStr, > InsertBefore) { > assert(pred >= CmpInst::FIRST_ICMP_PREDICATE && > pred <= CmpInst::LAST_ICMP_PREDICATE && > @@ -629,7 +630,7 @@ > assert(getOperand(0)->getType() == getOperand(1)->getType() && > "Both operands to ICmp instruction are not of the same > type!"); > // Check that the operands are the right type > - assert((getOperand(0)->getType()->isInteger() || > + assert((getOperand(0)->getType()->isIntOrIntVector() || > isa(getOperand(0)->getType())) && > "Invalid operand types for ICmp instruction"); > } > @@ -641,7 +642,8 @@ > Value *RHS, ///< The right-hand-side of the expression > const std::string &NameStr, ///< Name of the instruction > BasicBlock *InsertAtEnd ///< Block to insert into. > - ) : CmpInst(Type::Int1Ty, Instruction::ICmp, pred, LHS, RHS, > NameStr, > + ) : CmpInst(makeCmpResultType(LHS->getType()), > + Instruction::ICmp, pred, LHS, RHS, NameStr, > InsertAtEnd) { > assert(pred >= CmpInst::FIRST_ICMP_PREDICATE && > pred <= CmpInst::LAST_ICMP_PREDICATE && > @@ -649,7 +651,7 @@ > assert(getOperand(0)->getType() == getOperand(1)->getType() && > "Both operands to ICmp instruction are not of the same > type!"); > // Check that the operands are the right type > - assert((getOperand(0)->getType()->isInteger() || > + assert((getOperand(0)->getType()->isIntOrIntVector() || > isa(getOperand(0)->getType())) && > "Invalid operand types for ICmp instruction"); > } > @@ -754,6 +756,7 @@ > static inline bool classof(const Value *V) { > return isa(V) && classof(cast(V)); > } > + > }; > > // > = > = > = > ----------------------------------------------------------------------= > ==// > @@ -773,14 +776,15 @@ > Value *RHS, ///< The right-hand-side of the expression > const std::string &NameStr = "", ///< Name of the instruction > Instruction *InsertBefore = 0 ///< Where to insert > - ) : CmpInst(Type::Int1Ty, Instruction::FCmp, pred, LHS, RHS, > NameStr, > + ) : CmpInst(makeCmpResultType(LHS->getType()), > + Instruction::FCmp, pred, LHS, RHS, NameStr, > InsertBefore) { > assert(pred <= FCmpInst::LAST_FCMP_PREDICATE && > "Invalid FCmp predicate value"); > assert(getOperand(0)->getType() == getOperand(1)->getType() && > "Both operands to FCmp instruction are not of the same > type!"); > // Check that the operands are the right type > - assert(getOperand(0)->getType()->isFloatingPoint() && > + assert(getOperand(0)->getType()->isFPOrFPVector() && > "Invalid operand types for FCmp instruction"); > } > > @@ -791,14 +795,15 @@ > Value *RHS, ///< The right-hand-side of the expression > const std::string &NameStr, ///< Name of the instruction > BasicBlock *InsertAtEnd ///< Block to insert into. > - ) : CmpInst(Type::Int1Ty, Instruction::FCmp, pred, LHS, RHS, > NameStr, > + ) : CmpInst(makeCmpResultType(LHS->getType()), > + Instruction::FCmp, pred, LHS, RHS, NameStr, > InsertAtEnd) { > assert(pred <= FCmpInst::LAST_FCMP_PREDICATE && > "Invalid FCmp predicate value"); > assert(getOperand(0)->getType() == getOperand(1)->getType() && > "Both operands to FCmp instruction are not of the same > type!"); > // Check that the operands are the right type > - assert(getOperand(0)->getType()->isFloatingPoint() && > + assert(getOperand(0)->getType()->isFPOrFPVector() && > "Invalid operand types for FCmp instruction"); > } > > @@ -837,6 +842,7 @@ > static inline bool classof(const Value *V) { > return isa(V) && classof(cast(V)); > } > + > }; > > // > = > = > = > ----------------------------------------------------------------------= > ==// > > Modified: llvm/trunk/lib/AsmParser/llvmAsmParser.y > URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/AsmParser/llvmAsmParser.y?rev=55969&r1=55968&r2=55969&view=diff > > = > = > = > = > = > = > = > = > ====================================================================== > --- llvm/trunk/lib/AsmParser/llvmAsmParser.y (original) > +++ llvm/trunk/lib/AsmParser/llvmAsmParser.y Mon Sep 8 20:02:47 2008 > @@ -1102,7 +1102,7 @@ > %token ADD SUB MUL UDIV SDIV FDIV UREM SREM FREM AND > OR XOR > %token SHL LSHR ASHR > > -%token ICMP FCMP VICMP VFCMP > +%token ICMP FCMP VICMP VFCMP > %type IPredicates > %type FPredicates > %token EQ NE SLT SGT SLE SGE ULT UGT ULE UGE > @@ -3097,8 +3097,6 @@ > | ICMP IPredicates Types ValueRef ',' ValueRef { > if (!UpRefs.empty()) > GEN_ERROR("Invalid upreference in type: " + (*$3)- > >getDescription()); > - if (isa((*$3).get())) > - GEN_ERROR("Vector types not supported by icmp instruction"); > Value* tmpVal1 = getVal(*$3, $4); > CHECK_FOR_ERROR > Value* tmpVal2 = getVal(*$3, $6); > @@ -3111,8 +3109,6 @@ > | FCMP FPredicates Types ValueRef ',' ValueRef { > if (!UpRefs.empty()) > GEN_ERROR("Invalid upreference in type: " + (*$3)- > >getDescription()); > - if (isa((*$3).get())) > - GEN_ERROR("Vector types not supported by fcmp instruction"); > Value* tmpVal1 = getVal(*$3, $4); > CHECK_FOR_ERROR > Value* tmpVal2 = getVal(*$3, $6); > @@ -3133,7 +3129,7 @@ > CHECK_FOR_ERROR > $$ = CmpInst::Create($1, $2, tmpVal1, tmpVal2); > if ($$ == 0) > - GEN_ERROR("icmp operator returned null"); > + GEN_ERROR("vicmp operator returned null"); > delete $3; > } > | VFCMP FPredicates Types ValueRef ',' ValueRef { > @@ -3147,7 +3143,7 @@ > CHECK_FOR_ERROR > $$ = CmpInst::Create($1, $2, tmpVal1, tmpVal2); > if ($$ == 0) > - GEN_ERROR("fcmp operator returned null"); > + GEN_ERROR("vfcmp operator returned null"); > delete $3; > } > | CastOps ResolvedVal TO Types { > @@ -3163,10 +3159,23 @@ > delete $4; > } > | SELECT ResolvedVal ',' ResolvedVal ',' ResolvedVal { > - if ($2->getType() != Type::Int1Ty) > - GEN_ERROR("select condition must be boolean"); > + if (isa($2->getType())) { > + // vector select > + if (!isa($4->getType()) > + || !isa($6->getType()) ) > + GEN_ERROR("vector select value types must be vector types"); > + const VectorType* cond_type = cast($2->getType()); > + const VectorType* select_type = cast($4- > >getType()); > + if (cond_type->getElementType() != Type::Int1Ty) > + GEN_ERROR("vector select condition element type must be > boolean"); > + if (cond_type->getNumElements() != select_type- > >getNumElements()) > + GEN_ERROR("vector select number of elements must be the > same"); > + } else { > + if ($2->getType() != Type::Int1Ty) > + GEN_ERROR("select condition must be boolean"); > + } > if ($4->getType() != $6->getType()) > - GEN_ERROR("select value types should match"); > + GEN_ERROR("select value types must match"); > $$ = SelectInst::Create($2, $4, $6); > CHECK_FOR_ERROR > } > > Modified: llvm/trunk/lib/Bitcode/Reader/BitcodeReader.cpp > URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Bitcode/Reader/BitcodeReader.cpp?rev=55969&r1=55968&r2=55969&view=diff > > = > = > = > = > = > = > = > = > ====================================================================== > --- llvm/trunk/lib/Bitcode/Reader/BitcodeReader.cpp (original) > +++ llvm/trunk/lib/Bitcode/Reader/BitcodeReader.cpp Mon Sep 8 > 20:02:47 2008 > @@ -1499,8 +1499,19 @@ > Value *TrueVal, *FalseVal, *Cond; > if (getValueTypePair(Record, OpNum, NextValueNo, TrueVal) || > getValue(Record, OpNum, TrueVal->getType(), FalseVal) || > - getValue(Record, OpNum, Type::Int1Ty, Cond)) > + getValue(Record, OpNum, 0 /*skip type check*/, Cond)) > return Error("Invalid SELECT record"); > + > + // select condition can be either i1 or [N x i1] > + if (const VectorType* vector_type = dyn_cast VectorType>(Cond->getType())) { > + // expect > + if (vector_type->getElementType() != Type::Int1Ty) > + return Error("Invalid SELECT condition type"); > + } else { > + // expect i1 > + if (Cond->getType() != Type::Int1Ty) > + return Error("Invalid SELECT condition type"); > + } > > I = SelectInst::Create(Cond, TrueVal, FalseVal); > break; > @@ -1563,6 +1574,22 @@ > I = new VICmpInst((ICmpInst::Predicate)Record[OpNum], LHS, > RHS); > break; > } > + case bitc::FUNC_CODE_INST_VCMP: { // VCMP: [opty, opval, opval, > pred] > + // Fcmp/ICmp returning vector of bool > + unsigned OpNum = 0; > + Value *LHS, *RHS; > + if (getValueTypePair(Record, OpNum, NextValueNo, LHS) || > + getValue(Record, OpNum, LHS->getType(), RHS) || > + OpNum+1 != Record.size()) > + return Error("Invalid VCMP record"); > + > + // will always be vector > + if (LHS->getType()->isFPOrFPVector()) > + I = new FCmpInst((FCmpInst::Predicate)Record[OpNum], LHS, > RHS); > + else > + I = new ICmpInst((ICmpInst::Predicate)Record[OpNum], LHS, > RHS); > + break; > + } > case bitc::FUNC_CODE_INST_GETRESULT: { // GETRESULT: [ty, val, n] > if (Record.size() != 2) > return Error("Invalid GETRESULT record"); > > Modified: llvm/trunk/lib/Bitcode/Writer/BitcodeWriter.cpp > URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Bitcode/Writer/BitcodeWriter.cpp?rev=55969&r1=55968&r2=55969&view=diff > > = > = > = > = > = > = > = > = > ====================================================================== > --- llvm/trunk/lib/Bitcode/Writer/BitcodeWriter.cpp (original) > +++ llvm/trunk/lib/Bitcode/Writer/BitcodeWriter.cpp Mon Sep 8 > 20:02:47 2008 > @@ -641,7 +641,14 @@ > case Instruction::FCmp: > case Instruction::VICmp: > case Instruction::VFCmp: > - Code = bitc::CST_CODE_CE_CMP; > + if (isa(C->getOperand(0)->getType()) > + && (CE->getOpcode() == Instruction::ICmp > + || CE->getOpcode() == Instruction::FCmp)) { > + // compare returning vector of Int1Ty > + assert(0 && "Unsupported constant!"); > + } else { > + Code = bitc::CST_CODE_CE_CMP; > + } > Record.push_back(VE.getTypeID(C->getOperand(0)->getType())); > Record.push_back(VE.getValueID(C->getOperand(0))); > Record.push_back(VE.getValueID(C->getOperand(1))); > @@ -765,7 +772,14 @@ > case Instruction::FCmp: > case Instruction::VICmp: > case Instruction::VFCmp: > - Code = bitc::FUNC_CODE_INST_CMP; > + if (isa(I.getOperand(0)->getType()) > + && (I.getOpcode() == Instruction::ICmp > + || I.getOpcode() == Instruction::FCmp)) { > + // compare returning vector of Int1Ty > + Code = bitc::FUNC_CODE_INST_VCMP; > + } else { > + Code = bitc::FUNC_CODE_INST_CMP; > + } > PushValueAndType(I.getOperand(0), InstID, Vals, VE); > Vals.push_back(VE.getValueID(I.getOperand(1))); > Vals.push_back(cast(I).getPredicate()); > > Modified: llvm/trunk/lib/VMCore/Verifier.cpp > URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/VMCore/Verifier.cpp?rev=55969&r1=55968&r2=55969&view=diff > > = > = > = > = > = > = > = > = > ====================================================================== > --- llvm/trunk/lib/VMCore/Verifier.cpp (original) > +++ llvm/trunk/lib/VMCore/Verifier.cpp Mon Sep 8 20:02:47 2008 > @@ -659,8 +659,21 @@ > } > > void Verifier::visitSelectInst(SelectInst &SI) { > - Assert1(SI.getCondition()->getType() == Type::Int1Ty, > - "Select condition type must be bool!", &SI); > + if (const VectorType* vt > + = dyn_cast(SI.getCondition()->getType())) { > + Assert1( vt->getElementType() == Type::Int1Ty, > + "Select condition type must be vector of bool!", &SI); > + if (const VectorType* val_vt > + = dyn_cast(SI.getTrueValue()->getType())) { > + Assert1( vt->getNumElements() == val_vt->getNumElements(), > + "Select vector size != value vector size", &SI); > + } else { > + Assert1(0, "Vector select values must have vector types", &SI); > + } > + } else { > + Assert1(SI.getCondition()->getType() == Type::Int1Ty, > + "Select condition type must be bool!", &SI); > + } > Assert1(SI.getTrueValue()->getType() == SI.getFalseValue()- > >getType(), > "Select values must have identical types!", &SI); > Assert1(SI.getTrueValue()->getType() == SI.getType(), > @@ -1028,7 +1041,7 @@ > Assert1(Op0Ty == Op1Ty, > "Both operands to ICmp instruction are not of the same > type!", &IC); > // Check that the operands are the right type > - Assert1(Op0Ty->isInteger() || isa(Op0Ty), > + Assert1(Op0Ty->isIntOrIntVector() || isa(Op0Ty), > "Invalid operand types for ICmp instruction", &IC); > visitInstruction(IC); > } > @@ -1040,7 +1053,7 @@ > Assert1(Op0Ty == Op1Ty, > "Both operands to FCmp instruction are not of the same > type!", &FC); > // Check that the operands are the right type > - Assert1(Op0Ty->isFloatingPoint(), > + Assert1(Op0Ty->isFPOrFPVector(), > "Invalid operand types for FCmp instruction", &FC); > visitInstruction(FC); > } > > Added: llvm/trunk/test/Assembler/vbool-cmp.ll > URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Assembler/vbool-cmp.ll?rev=55969&view=auto > > = > = > = > = > = > = > = > = > ====================================================================== > --- llvm/trunk/test/Assembler/vbool-cmp.ll (added) > +++ llvm/trunk/test/Assembler/vbool-cmp.ll Mon Sep 8 20:02:47 2008 > @@ -0,0 +1,15 @@ > +; RUN: llvm-as < %s | llvm-dis | llvm-as | llvm-dis | grep {icmp slt} > +; rudimentary test of fcmp/icmp on vectors returning vector of bool > + > +define <4 x i1> @ffoo(<4 x float> %a, <4 x float> %b) nounwind { > +entry: > + %cmp = fcmp olt <4 x float> %a, %b ; <4 x i1> [#uses=1] > + ret <4 x i1> %cmp > +} > + > +define <4 x i1> @ifoo(<4 x i32> %a, <4 x i32> %b) nounwind { > +entry: > + %cmp = icmp slt <4 x i32> %a, %b ; <4 x i1> [#uses=1] > + ret <4 x i1> %cmp > +} > + > > Added: llvm/trunk/test/Assembler/vector-select.ll > URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Assembler/vector-select.ll?rev=55969&view=auto > > = > = > = > = > = > = > = > = > ====================================================================== > --- llvm/trunk/test/Assembler/vector-select.ll (added) > +++ llvm/trunk/test/Assembler/vector-select.ll Mon Sep 8 20:02:47 > 2008 > @@ -0,0 +1,11 @@ > +; RUN: llvm-as < %s | llvm-dis | llvm-as | llvm-dis | grep select > +; rudimentary test of select on vectors returning vector of bool > + > +define <4 x i32> @foo(<4 x i32> %a, <4 x i32> %b, > + <4 x i1> %cond) nounwind { > +entry: > + %cmp = select <4 x i1> %cond, <4 x i32> %a, <4 x i32> %b > + ; <4 x i32> [#uses=1] > + ret <4 x i32> %cmp > +} > + > > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From evan.cheng at apple.com Mon Sep 22 01:30:38 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Sun, 21 Sep 2008 23:30:38 -0700 Subject: [llvm-commits] [llvm] r55807 - in /llvm/trunk: lib/Target/X86/X86CallingConv.td lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/2007-08-13-SpillerReuse.ll test/CodeGen/X86/2008-02-22-ReMatBug.ll test/CodeGen/X86/coalescer-commute3.ll test/CodeGen/X86/combine-lds.ll test/CodeGen/X86/fastcc.ll In-Reply-To: <484E2891-5028-440E-9C25-875007E6FC66@apple.com> References: <200809042259.m84MxxkM017095@zion.cs.uiuc.edu> <484E2891-5028-440E-9C25-875007E6FC66@apple.com> Message-ID: <4CA8151C-767A-4CE9-B712-0DDDB11F2217@apple.com> On Sep 21, 2008, at 12:47 PM, Chris Lattner wrote: > > On Sep 4, 2008, at 3:59 PM, Evan Cheng wrote: > >> Author: evancheng >> Date: Thu Sep 4 17:59:58 2008 >> New Revision: 55807 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=55807&view=rev >> Log: >> For whatever the reason, x86 CallingConv::Fast (i.e. fastcc) was >> not passing scalar arguments in registers. This patch defines a new >> fastcc CC which is slightly different from the FastCall CC. In >> addition to passing integer arguments in ECX and EDX, it also >> specify doubles are passed in 8-byte slots which are 8-byte aligned >> (instead of 4-byte aligned). This avoids a potential performance >> hazard where doubles span cacheline boundaries. > > Okay, cool but: > >> @@ -1100,6 +1100,8 @@ >> return CC_X86_32_FastCall; >> else if (CC == CallingConv::Fast && PerformTailCallOpt) >> return CC_X86_32_TailCall; >> + else if (CC == CallingConv::Fast) >> + return CC_X86_32_FastCC; > > Does this mean that "PerformTailCallOpt" changes the ABI? Looks that way. The difference is rather confusing: TailCall: // Nested function trampolines are currently not supported by fastcc. // The first 3 integer arguments, if marked 'inreg' and if the call is not // a vararg call, are passed in integer registers. CCIfNotVarArg>>>, FastCC: // The 'nest' parameter, if any, is passed in EAX. CCIfNest>, // The first 2 integer arguments are passed in ECX/EDX CCIfType<[i32], CCAssignToReg<[ECX, EDX]>>, First of all, the comment about "nested function not being supported by fastcc" looks wrong. Secondly, it's not clear to me why the integer registers have to be marked inreg to be passed in registers (only EAX, EDX, what's the 3rd). Arnold, any ideas? Evan > > > -Chris > From evan.cheng at apple.com Mon Sep 22 01:45:42 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Sun, 21 Sep 2008 23:45:42 -0700 Subject: [llvm-commits] [llvm] r56310 - /llvm/trunk/lib/CodeGen/DeadMachineInstructionElim.cpp In-Reply-To: <615BE1D9-7BFE-4828-B769-EB796B034932@apple.com> References: <200809181822.m8IIMW2k002887@zion.cs.uiuc.edu> <47A144A2-3B20-467D-8EAA-FB90DF12E434@apple.com> <615BE1D9-7BFE-4828-B769-EB796B034932@apple.com> Message-ID: On Sep 21, 2008, at 11:17 PM, Chris Lattner wrote: > > On Sep 21, 2008, at 11:09 PM, Evan Cheng wrote: > >> Local liveness hasn't been split out from livevariables. The plan is >> for DCE to track local liveness. > > Ok! That would be great, considering it is already doing a backward > scan. Would the register scavenger regtracker help with this? That also works top down. If we really want accurate local liveness (and want to set kill / def markers, perhaps we can reuse RALocal::ComputeLocalLiveness(). Previously we thought this won't be necessary. But perhaps it's a good idea. If we move RALocal::ComputeLocalLiveness out to a analysis pass, then DCE can use and update it and that eliminate the need for local register allocator to run it. Ultimately we want to split LiveVariables into local physical register liveness and global virtual register liveness. But this is a good step. Evan > > > -Chris > >> >> >> Evan >> >> On Sep 21, 2008, at 8:27 PM, Chris Lattner wrote: >> >>> >>> On Sep 21, 2008, at 7:42 PM, Evan Cheng wrote: >>> >>>> This happens before livevariables. Remember we don't run LV at -O0. >>> >>> Not even local liveness? That would be enough to handle physregs. >>> >>> -Chris >>> >>> _______________________________________________ >>> llvm-commits mailing list >>> llvm-commits at cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >> >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From evan.cheng at apple.com Mon Sep 22 01:52:10 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Sun, 21 Sep 2008 23:52:10 -0700 Subject: [llvm-commits] [llvm] r56384 - in /llvm/trunk/lib/CodeGen: RegAllocLinearScan.cpp SimpleRegisterCoalescing.cpp In-Reply-To: References: <200809200203.m8K234YA013252@zion.cs.uiuc.edu> <4F71A860-E342-4A07-8211-0A59A1AA154D@apple.com> <8D81D6DA-8289-49E2-B352-53C6C313FDA8@apple.com> <33791BFC-A09D-43EB-B4D0-6582A9243EED@apple.com> Message-ID: <6AABEF56-39B2-4D47-8928-7FC4AC7AB61B@apple.com> On Sep 21, 2008, at 11:19 PM, Chris Lattner wrote: > On Sep 21, 2008, at 11:17 PM, Evan Cheng wrote: >>>> While that's the correct approach, it breaks all kinds of >>>> assumptions >>>> in liveintervals and the coalescer. It will make the problem much >>>> more >>>> complicated. I don't think it's worth the effort. >>> >>> What sorts of assumptions? >> >> That use must be 1 cycle after instruction cycle, def must be 2 >> cycles >> after it. > > What code makes this sort of assumption? It seems fragile. It's all over the place in coalescer. I'd prefer to fix it only when it's necessary. Not for early clobber. > > >>> It typically doesn't have anything to do with a micro architecture, >>> it >>> has to do with the fact that an inline asm has multiple >>> instructions. >>> For example if you had an inline asm with: >>> >>> "$out0 = inst1 $in1, 4 >>> $out1 = inst2 $in2, 142" >>> >>> Then you'd have to mark $out0 as being an early clobber, because it >>> is >>> stored to before $in2 is read. >> >> Ewwww. > > Eww what? You don't like asms with multiple instructions? Or you > prefer CPUs that have instructions that would require this? ;-) Ewww multi- instruction asm with this horribleness. Some in-order execution cpu's may require this. Usually it would require HW bypass for reads to completed early enough for def to target the same registers. It's quite common for some instructions to not have the benefit of bypass in some in-order machines. Evan > > > -Chris > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From viridia at gmail.com Mon Sep 22 02:14:46 2008 From: viridia at gmail.com (Talin) Date: Mon, 22 Sep 2008 00:14:46 -0700 Subject: [llvm-commits] [llvm] r55409 - in /llvm/trunk: include/llvm/Support/DebugInfoBuilder.h lib/VMCore/DebugInfoBuilder.cpp In-Reply-To: <1EB8BE6B-6CC8-445E-B964-BF7DE2FA7637@apple.com> References: <200808270651.m7R6pFf1026223@zion.cs.uiuc.edu> <1EB8BE6B-6CC8-445E-B964-BF7DE2FA7637@apple.com> Message-ID: <48D745E6.8060004@gmail.com> That all sounds good to me. I would welcome a more abstract interface to generating debug information. I would be tempted to take the proposal even a step further. In the current system, debugging information is represented using the same data structures that are used to build up global constants and variables - in other words, the debugging info is "encoded" using non-debugging LLVM IR primitives. The proposal moves in the direction of having specialized types and data structures that are optimized for representing debug information. It might be possible to go even farther, and create specialized representations (both in text and binary form) for debugging primitives that do not depend on the normal non-debugging data structrures, allowing the debug info to be as compact, type-safe, and convenient to use as possible. (I would say more but I am recovering from a wrist injury and typing is painful.) Chris Lattner wrote: > > On Aug 26, 2008, at 11:51 PM, Evan Cheng wrote: > >> Author: evancheng >> Date: Wed Aug 27 01:51:14 2008 >> New Revision: 55409 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=55409&view=rev >> Log: >> Add DebugInfoBuilder. Patch by Talin! > > Hi Talin, > > Your DebugInfoBuilder looks very nice. Have you had a chance to look > at this proposal? > http://nondot.org/sabre/LLVMNotes/EmbeddedMetadata.txt > > One piece of it (that is orthogonal from the rest) is the 'Debug Info > Construction/Manipulation Helper Classes' section. I hadn't had a > chance to dig into your debug info builder before writing that, but I > now see that they are very very related. > > Between the two, I think that my proposal would be preferable because > it would give better type info, and lend itself to clients that want > to walk existing debug info, instead of just creating debug info. The > other advantage of my proposal is that it would insulate clients from > changes in the debug info representation: the debug classes could be > based on GlobalVariables today, but the implementation could change > under the covers to use MDNodes in the future with no or little > changes to the clients. > > What are your thoughts? If we converge on this, I'd like to convert > clang and llvm-gcc over to use the interface we finalize on (probably > post 2.4). > > -Chris > > From baldrick at free.fr Mon Sep 22 02:22:11 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 22 Sep 2008 09:22:11 +0200 Subject: [llvm-commits] [llvm] r55859 - in /llvm/trunk: include/llvm/Analysis/CallGraph.h lib/Analysis/IPA/CallGraph.cpp lib/Transforms/IPO/PruneEH.cpp lib/Transforms/Utils/InlineFunction.cpp In-Reply-To: <359F1A29-F6E0-402E-B8ED-7E95C4EBE427@apple.com> References: <200809052143.m85Lh5AS012722@zion.cs.uiuc.edu> <359F1A29-F6E0-402E-B8ED-7E95C4EBE427@apple.com> Message-ID: <200809220922.12032.baldrick@free.fr> > Nice! Does this allow the patch in http://llvm.org/bugs/show_bug.cgi?id=2221 > to go in now? No need for that patch - I already made the change independently! As far as I know I resolved all the issues mentioned in that PR. Ciao, Duncan. From baldrick at free.fr Mon Sep 22 02:37:47 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 22 Sep 2008 09:37:47 +0200 Subject: [llvm-commits] [llvm-gcc-4.2] r55796 - /llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp In-Reply-To: References: <200809042123.m84LNekC013647@zion.cs.uiuc.edu> <200809092138.09813.baldrick@free.fr> Message-ID: <200809220937.47428.baldrick@free.fr> > OTOH, a flavor of this is also a front-end issue: fortran code never > uses errno, so it is safe (in fortran) to optimize to a representation > that doesn't generate errno. Right, same with Ada. That's why the Ada front-end marks these kind of things 'const', causing them to end up 'readnone' in the IR. Ciao, Duncan. From baldrick at free.fr Mon Sep 22 02:54:33 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 22 Sep 2008 09:54:33 +0200 Subject: [llvm-commits] [llvm] r55807 - in /llvm/trunk: lib/Target/X86/X86CallingConv.td lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/2007-08-13-SpillerReuse.ll test/CodeGen/X86/2008-02-22-ReMatBug.ll test/CodeGen/X86/coalescer-commute3.ll test/CodeGen/X86/combine-lds.ll test/CodeGen/X86/fastcc.ll In-Reply-To: <4CA8151C-767A-4CE9-B712-0DDDB11F2217@apple.com> References: <200809042259.m84MxxkM017095@zion.cs.uiuc.edu> <484E2891-5028-440E-9C25-875007E6FC66@apple.com> <4CA8151C-767A-4CE9-B712-0DDDB11F2217@apple.com> Message-ID: <200809220954.33916.baldrick@free.fr> > > Does this mean that "PerformTailCallOpt" changes the ABI? Arnold already agreed that tailcall could use the new calling convention, i.e. be the same as fastcc. > First of all, the comment about "nested function not being supported > by fastcc" looks wrong. It is correct. The problem is that the tailcall logic reserves a register (ECX; would be EAX in new fastcc) for its own use. The trampoline stuff wants that same register to do trampoline stuff (it's the only spare register). If the two calling conventions are merged (i.e. tailcall cc dropped), there would be the problem of detecting that tailcall and trampoline are fighting for the same register, so an error can be issued. I think the right solution is to explicitly represent in the td that tailcall wants the register, in much the same way as trampoline stuff does. Something like this: CCIfTailCall>, Ciao, Duncan. PS: There might be other incompatibilities between tailcall and trampolines, but I can't say because I don't know what tailcall does exactly. From arnold.schwaighofer at gmail.com Mon Sep 22 04:31:22 2008 From: arnold.schwaighofer at gmail.com (Arnold Schwaighofer) Date: Mon, 22 Sep 2008 11:31:22 +0200 Subject: [llvm-commits] [llvm] r55807 - in /llvm/trunk: lib/Target/X86/X86CallingConv.td lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/2007-08-13-SpillerReuse.ll test/CodeGen/X86/2008-02-22-ReMatBug.ll test/CodeGen/X86/coalescer-commute3.ll test/Cod Message-ID: On Mon, Sep 22, 2008 at 9:54 AM, Duncan Sands wrote: >> > Does this mean that "PerformTailCallOpt" changes the ABI? > > Arnold already agreed that tailcall could use the new calling convention, > i.e. be the same as fastcc. > >> First of all, the comment about "nested function not being supported >> by fastcc" looks wrong. > > It is correct. The problem is that the tailcall logic reserves a > register (ECX; would be EAX in new fastcc) for its own use. The > trampoline stuff wants that same register to do trampoline stuff > (it's the only spare register). If the two calling conventions are > merged (i.e. tailcall cc dropped), there would be the problem of > detecting that tailcall and trampoline are fighting for the same > register, so an error can be issued. I think the right solution is > to explicitly represent in the td that tailcall wants the register, > in much the same way as trampoline stuff does. Something like this: Yes as duncan says tail call optimization requires a (caller saved) register for a function call via a pointer. That is why tailcall convention differs from the others. I initially created it by copying the std convention and modifying it. That's were the wrong comment regarding the three registers comes from it should actually read two registers are available. There actually is no reason that prevents CC_X86_32_TailCall from being replaced by CC_X86_32_FastCC. (eax would be used as the function pointer register, also see discussion ). I wanted to change that but have not come around to do it yet. BUT there still is an ABI difference when -tailcallopt is enabled. To support general tail call optimization (in cases where the callee can require more room for its arguments than the caller provides) the calling convention is changed from caller pops arguments to callee pops arguments. This is necessary as the caller does not know how many arguments there are to pop in cases where the called function performs a tail call itself. (caller() calls callee(a,b) tailcalls calleecallee(a,b,c,d), how many arguments are there to pop for caller 2 or 4) So in cases where a library would be compiled with -tailcallopt enabled and a the program using the library would be compiled without -tailcallopt all hell would break loose. Possible solutions: - Document this fact! ;) - Only optimize sibling tail calls (callee argument area <= caller argument area, calller pops arguments can be used) with fastcc calls and create a new calling convention TailCall which is always 'callee pops arguments' even if -tailcallopt is not enabled. regards arnold From rafael.espindola at gmail.com Mon Sep 22 05:06:27 2008 From: rafael.espindola at gmail.com (Rafael Espindola) Date: Mon, 22 Sep 2008 10:06:27 -0000 Subject: [llvm-commits] [llvm] r56432 - /llvm/trunk/include/llvm/ADT/SmallVector.h Message-ID: <200809221006.m8MA6SB2014517@zion.cs.uiuc.edu> Author: rafael Date: Mon Sep 22 05:06:26 2008 New Revision: 56432 URL: http://llvm.org/viewvc/llvm-project?rev=56432&view=rev Log: Add bound checks in SmallVector Modified: llvm/trunk/include/llvm/ADT/SmallVector.h Modified: llvm/trunk/include/llvm/ADT/SmallVector.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/SmallVector.h?rev=56432&r1=56431&r2=56432&view=diff ============================================================================== --- llvm/trunk/include/llvm/ADT/SmallVector.h (original) +++ llvm/trunk/include/llvm/ADT/SmallVector.h Mon Sep 22 05:06:26 2008 @@ -19,6 +19,7 @@ #include #include #include +#include #ifdef _MSC_VER namespace std { @@ -116,10 +117,14 @@ const_reverse_iterator rend() const { return const_reverse_iterator(begin());} + /* These asserts could be "Begin + idx < End", but there are lots of places + in llvm where we use &v[v.size()] instead of v.end(). */ reference operator[](unsigned idx) { + assert (Begin + idx <= End); return Begin[idx]; } const_reference operator[](unsigned idx) const { + assert (Begin + idx <= End); return Begin[idx]; } From arnold.schwaighofer at gmail.com Mon Sep 22 06:09:21 2008 From: arnold.schwaighofer at gmail.com (Arnold Schwaighofer) Date: Mon, 22 Sep 2008 13:09:21 +0200 Subject: [llvm-commits] [llvm] r55807 - in /llvm/trunk: lib/Target/X86/X86CallingConv.td lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/2007-08-13-SpillerReuse.ll test/CodeGen/X86/2008-02-22-ReMatBug.ll test/CodeGen/X86/coalescer-commute3.ll test/Cod Message-ID: > TailCall: > // Nested function trampolines are currently not supported by fastcc. Should read: Nested function trampolines are currently not supported by fastcc when -tailcallopt is enabled because i don't know the implications of trampolines. > // The first 3 integer arguments, if marked 'inreg' and if the call is not > // a vararg call, are passed in integer registers. > CCIfNotVarArg>>>, Should read: // the first 2 > FastCC: > // The 'nest' parameter, if any, is passed in EAX. > CCIfNest>, > > // The first 2 integer arguments are passed in ECX/EDX > CCIfType<[i32], CCAssignToReg<[ECX, EDX]>>, > > First of all, the comment about "nested function not being supported by > fastcc" looks wrong. Secondly, it's not clear to me why the integer > registers have to be marked inreg to be passed in registers (only EAX, EDX, > what's the 3rd). Arnold, any ideas? The only 'reason' is that the calling convention was a copy of the std convention. From baldrick at free.fr Mon Sep 22 06:32:54 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 22 Sep 2008 13:32:54 +0200 Subject: [llvm-commits] [llvm] r55807 - in /llvm/trunk: lib/Target/X86/X86CallingConv.td lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/2007-08-13-SpillerReuse.ll test/CodeGen/X86/2008-02-22-ReMatBug.ll test/CodeGen/X86/coalescer-commute3.ll test/Cod In-Reply-To: References: Message-ID: <200809221332.54305.baldrick@free.fr> Hi Arnold, > Nested function trampolines are currently not supported by fastcc when > -tailcallopt is enabled because i don't know the implications of > trampolines. trampolines work like this. Suppose you have a function i32 @f(i8* nest, i32, i32) Then a trampoline lets you call it as if it didn't take the first parameter (the one marked with the nest attribute), i.e. as if it looked like this: i32 @f_tramp(i32, i32) The value V to be passed as the i8* is specified when you create the trampoline. The trampoline intrinsic hands you a pointer P to a i32(i32, i32) function. If someone does a call i32(i32, i32)* P(i32 x, i32 y) then the trampoline magic splices in the value for V, and the effect is as if you called @f(i8* V, i32 x, i32 y). Yes, this is actually useful :) How is this implemented? The code generators create a bit of executable code on the stack that does: load V into ecx <= register reserved by trampoline jump to @f The pointer P returned by the trampoline intrinsic points to the "load V into ecx" instruction on the stack. A call to P then results in a call to @f with V held in ecx. And that's it. I have no idea how this interacts with tail calls. Since the call to the trampoline is always an indirect call, maybe it never gets turned into a tail call? Ciao, Duncan. From baldrick at free.fr Mon Sep 22 09:46:39 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 22 Sep 2008 16:46:39 +0200 Subject: [llvm-commits] [llvm] r56337 - in /llvm/trunk: test/Analysis/CallGraph/2008-09-09-DirectCall.ll test/Analysis/CallGraph/2008-09-09-UsedByGlobal.ll test/Other/2002-01-31-CallGraph.ll tools/opt/AnalysisWrappers.cpp In-Reply-To: <0EE8C571-DA8D-4C9A-BE3F-F63486A77CB8@apple.com> References: <200809190757.m8J7vA0C007167@zion.cs.uiuc.edu> <0EE8C571-DA8D-4C9A-BE3F-F63486A77CB8@apple.com> Message-ID: <200809221646.39541.baldrick@free.fr> Hi Devang, > How about renaming -callgraph as -dump-callgraph ? opt has the following options that print info. -callgraph - Print a call graph -callscc - Print SCCs of the Call Graph -cfgscc - Print SCCs of each function CFG -externalfnconstants - Print external fn callsites passed constants -print - Print function to stderr -print-alias-sets - Alias Set Printer -print-callgraph - Print Call Graph to 'dot' file -print-cfg - Print CFG of function to 'dot' file -print-cfg-only - Print CFG of function to 'dot' file (with no function bodies) -print-dom-info - Dominator Info Printer -printm - Print module to stderr -printusedtypes - Find Used Types It seems a bit of a mess. What do you think of the following changes: -callgraph => print-callgraph -callscc => print-callgraph-sccs -cfgscc => print-cfg-sccs -externalfnconstants => print-externalfnconstants -print => print-function -print-alias-sets (no change) -print-callgraph => dot-callgraph -print-cfg => dot-cfg -print-cfg-only => dot-cfg-only -print-dom-info (no change) -printm => print-module -printusedtypes => print-used-types ? Ciao, Duncan. From arnold.schwaighofer at gmail.com Mon Sep 22 09:50:07 2008 From: arnold.schwaighofer at gmail.com (Arnold Schwaighofer) Date: Mon, 22 Sep 2008 14:50:07 -0000 Subject: [llvm-commits] [llvm] r56436 - in /llvm/trunk: lib/Target/X86/X86CallingConv.td lib/Target/X86/X86FastISel.cpp lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/tailcall-stackalign.ll test/CodeGen/X86/tailcallbyval.ll test/CodeGen/X86/tailcallfp2.ll Message-ID: <200809221450.m8MEo8Tc003842@zion.cs.uiuc.edu> Author: arnolds Date: Mon Sep 22 09:50:07 2008 New Revision: 56436 URL: http://llvm.org/viewvc/llvm-project?rev=56436&view=rev Log: Change the calling convention used when tail call optimization is enabled from CC_X86_32_TailCall to CC_X86_32_FastCC. Modified: llvm/trunk/lib/Target/X86/X86CallingConv.td llvm/trunk/lib/Target/X86/X86FastISel.cpp llvm/trunk/lib/Target/X86/X86ISelLowering.cpp llvm/trunk/test/CodeGen/X86/tailcall-stackalign.ll llvm/trunk/test/CodeGen/X86/tailcallbyval.ll llvm/trunk/test/CodeGen/X86/tailcallfp2.ll Modified: llvm/trunk/lib/Target/X86/X86CallingConv.td URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86CallingConv.td?rev=56436&r1=56435&r2=56436&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86CallingConv.td (original) +++ llvm/trunk/lib/Target/X86/X86CallingConv.td Mon Sep 22 09:50:07 2008 @@ -312,22 +312,6 @@ CCDelegateTo ]>; -/// Same as C calling convention except for non-free ECX which is used for storing -/// a potential pointer to the tail called function. -def CC_X86_32_TailCall : CallingConv<[ - // Promote i8/i16 arguments to i32. - CCIfType<[i8, i16], CCPromoteToType>, - - // Nested function trampolines are currently not supported by fastcc. - - // The first 3 integer arguments, if marked 'inreg' and if the call is not - // a vararg call, are passed in integer registers. - CCIfNotVarArg>>>, - - // Otherwise, same as everything else. - CCDelegateTo -]>; - def CC_X86_32_FastCall : CallingConv<[ // Promote i8/i16 arguments to i32. CCIfType<[i8, i16], CCPromoteToType>, Modified: llvm/trunk/lib/Target/X86/X86FastISel.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86FastISel.cpp?rev=56436&r1=56435&r2=56436&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86FastISel.cpp (original) +++ llvm/trunk/lib/Target/X86/X86FastISel.cpp Mon Sep 22 09:50:07 2008 @@ -142,8 +142,6 @@ if (CC == CallingConv::X86_FastCall) return CC_X86_32_FastCall; - else if (CC == CallingConv::Fast && isTaillCall) - return CC_X86_32_TailCall; else if (CC == CallingConv::Fast) return CC_X86_32_FastCC; else Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86ISelLowering.cpp?rev=56436&r1=56435&r2=56436&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86ISelLowering.cpp (original) +++ llvm/trunk/lib/Target/X86/X86ISelLowering.cpp Mon Sep 22 09:50:07 2008 @@ -890,7 +890,7 @@ SDValue TargetAddress = TailCall.getOperand(1); SDValue StackAdjustment = TailCall.getOperand(2); assert(((TargetAddress.getOpcode() == ISD::Register && - (cast(TargetAddress)->getReg() == X86::ECX || + (cast(TargetAddress)->getReg() == X86::EAX || cast(TargetAddress)->getReg() == X86::R9)) || TargetAddress.getOpcode() == ISD::TargetExternalSymbol || TargetAddress.getOpcode() == ISD::TargetGlobalAddress) && @@ -1098,8 +1098,6 @@ if (CC == CallingConv::X86_FastCall) return CC_X86_32_FastCall; - else if (CC == CallingConv::Fast && PerformTailCallOpt) - return CC_X86_32_TailCall; else if (CC == CallingConv::Fast) return CC_X86_32_FastCC; else @@ -1700,7 +1698,7 @@ } else if (ExternalSymbolSDNode *S = dyn_cast(Callee)) { Callee = DAG.getTargetExternalSymbol(S->getSymbol(), getPointerTy()); } else if (IsTailCall) { - unsigned Opc = Is64Bit ? X86::R9 : X86::ECX; + unsigned Opc = Is64Bit ? X86::R9 : X86::EAX; Chain = DAG.getCopyToReg(Chain, DAG.getRegister(Opc, getPointerTy()), Modified: llvm/trunk/test/CodeGen/X86/tailcall-stackalign.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/tailcall-stackalign.ll?rev=56436&r1=56435&r2=56436&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/X86/tailcall-stackalign.ll (original) +++ llvm/trunk/test/CodeGen/X86/tailcall-stackalign.ll Mon Sep 22 09:50:07 2008 @@ -1,4 +1,4 @@ -; RUN: llvm-as < %s | llc -mtriple=i686-unknown-linux -tailcallopt | grep -A 1 call | grep -A 1 tailcaller | grep subl | grep 20 +; RUN: llvm-as < %s | llc -mtriple=i686-unknown-linux -tailcallopt | grep -A 1 call | grep -A 1 tailcaller | grep subl | grep 12 ; Linux has 8 byte alignment so the params cause stack size 20 when tailcallopt ; is enabled, ensure that a normal fastcc call has matching stack size Modified: llvm/trunk/test/CodeGen/X86/tailcallbyval.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/tailcallbyval.ll?rev=56436&r1=56435&r2=56436&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/X86/tailcallbyval.ll (original) +++ llvm/trunk/test/CodeGen/X86/tailcallbyval.ll Mon Sep 22 09:50:07 2008 @@ -1,6 +1,6 @@ ; RUN: llvm-as < %s | llc -march=x86 -tailcallopt | grep TAILCALL ; check for the 2 byval moves -; RUN: llvm-as < %s | llc -march=x86 -tailcallopt | grep rep | wc -l | grep 2 +; RUN: llvm-as < %s | llc -march=x86 -tailcallopt | grep movl | grep ecx | grep eax | wc -l | grep 1 %struct.s = type {i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32 } Modified: llvm/trunk/test/CodeGen/X86/tailcallfp2.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/tailcallfp2.ll?rev=56436&r1=56435&r2=56436&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/X86/tailcallfp2.ll (original) +++ llvm/trunk/test/CodeGen/X86/tailcallfp2.ll Mon Sep 22 09:50:07 2008 @@ -1,4 +1,4 @@ -; RUN: llvm-as < %s | llc -march=x86 -tailcallopt | grep {jmp} | grep {\\*%ecx} +; RUN: llvm-as < %s | llc -march=x86 -tailcallopt | grep {jmp} | grep {\\*%eax} declare i32 @putchar(i32) From clattner at apple.com Mon Sep 22 10:43:40 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 22 Sep 2008 08:43:40 -0700 Subject: [llvm-commits] [llvm] r55807 - in /llvm/trunk: lib/Target/X86/X86CallingConv.td lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/2007-08-13-SpillerReuse.ll test/CodeGen/X86/2008-02-22-ReMatBug.ll test/CodeGen/X86/coalescer-commute3.ll test/CodeGen/X86/combine-lds.ll test/CodeGen/X86/fastcc.ll In-Reply-To: <4CA8151C-767A-4CE9-B712-0DDDB11F2217@apple.com> References: <200809042259.m84MxxkM017095@zion.cs.uiuc.edu> <484E2891-5028-440E-9C25-875007E6FC66@apple.com> <4CA8151C-767A-4CE9-B712-0DDDB11F2217@apple.com> Message-ID: On Sep 21, 2008, at 11:30 PM, Evan Cheng wrote: > Secondly, it's not clear to me why the integer registers have to be > marked inreg to be passed in registers (only EAX, EDX, what's the > 3rd). Arnold, any ideas? I thought that this was how the normal x86-32 calling conv worked: Integer values are passed on the stack unless -mregparm (or attribute) is used, which tags the arguments with 'inreg' -Chris From clattner at apple.com Mon Sep 22 10:45:46 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 22 Sep 2008 08:45:46 -0700 Subject: [llvm-commits] [llvm] r56384 - in /llvm/trunk/lib/CodeGen: RegAllocLinearScan.cpp SimpleRegisterCoalescing.cpp In-Reply-To: <6AABEF56-39B2-4D47-8928-7FC4AC7AB61B@apple.com> References: <200809200203.m8K234YA013252@zion.cs.uiuc.edu> <4F71A860-E342-4A07-8211-0A59A1AA154D@apple.com> <8D81D6DA-8289-49E2-B352-53C6C313FDA8@apple.com> <33791BFC-A09D-43EB-B4D0-6582A9243EED@apple.com> <6AABEF56-39B2-4D47-8928-7FC4AC7AB61B@apple.com> Message-ID: <73CDDC9A-1C75-4A15-9931-12DDC51EABCB@apple.com> On Sep 21, 2008, at 11:52 PM, Evan Cheng wrote: > On Sep 21, 2008, at 11:19 PM, Chris Lattner wrote: >> On Sep 21, 2008, at 11:17 PM, Evan Cheng wrote: >>>>> While that's the correct approach, it breaks all kinds of >>>>> assumptions >>>>> in liveintervals and the coalescer. It will make the problem much >>>>> more >>>>> complicated. I don't think it's worth the effort. >>>> >>>> What sorts of assumptions? >>> >>> That use must be 1 cycle after instruction cycle, def must be 2 >>> cycles >>> after it. >> >> What code makes this sort of assumption? It seems fragile. > > It's all over the place in coalescer. I'd prefer to fix it only when > it's necessary. Not for early clobber. Can you give me an example? It sounds like these sorts of assumptions are exactly what we want: you can only coalesce a def/use of a copy if the live ranges exactly line up. Overlapping by one slot is a *good* thing because we want to prevent coalescing. >>>> Then you'd have to mark $out0 as being an early clobber, because it >>>> is >>>> stored to before $in2 is read. >>> >>> Ewwww. >> >> Eww what? You don't like asms with multiple instructions? Or you >> prefer CPUs that have instructions that would require this? ;-) > > Ewww multi- instruction asm with this horribleness. > > Some in-order execution cpu's may require this. Usually it would > require HW bypass for reads to completed early enough for def to > target the same registers. It's quite common for some instructions to > not have the benefit of bypass in some in-order machines. Can earlyclobber operands be used to model the armv4 "mul" register weirdness where the input and output regs can't be the same? -Chris From clattner at apple.com Mon Sep 22 10:46:44 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 22 Sep 2008 08:46:44 -0700 Subject: [llvm-commits] [llvm] r55859 - in /llvm/trunk: include/llvm/Analysis/CallGraph.h lib/Analysis/IPA/CallGraph.cpp lib/Transforms/IPO/PruneEH.cpp lib/Transforms/Utils/InlineFunction.cpp In-Reply-To: <200809220922.12032.baldrick@free.fr> References: <200809052143.m85Lh5AS012722@zion.cs.uiuc.edu> <359F1A29-F6E0-402E-B8ED-7E95C4EBE427@apple.com> <200809220922.12032.baldrick@free.fr> Message-ID: <02B8AE29-ECD2-473E-82CE-7E54A142D65B@apple.com> On Sep 22, 2008, at 12:22 AM, Duncan Sands wrote: >> Nice! Does this allow the patch in http://llvm.org/bugs/show_bug.cgi?id=2221 >> to go in now? > > No need for that patch - I already made the change independently! > As far as I know I resolved all the issues mentioned in that PR. Woo, even better. Thanks Duncan! -Chris From clattner at apple.com Mon Sep 22 10:50:43 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 22 Sep 2008 08:50:43 -0700 Subject: [llvm-commits] [llvm] r55807 - in /llvm/trunk: lib/Target/X86/X86CallingConv.td lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/2007-08-13-SpillerReuse.ll test/CodeGen/X86/2008-02-22-ReMatBug.ll test/CodeGen/X86/coalescer-commute3.ll test/Cod In-Reply-To: References: Message-ID: On Sep 22, 2008, at 2:31 AM, Arnold Schwaighofer wrote: > On Mon, Sep 22, 2008 at 9:54 AM, Duncan Sands > wrote: >>>> Does this mean that "PerformTailCallOpt" changes the ABI? >> >> Arnold already agreed that tailcall could use the new calling >> convention, >> i.e. be the same as fastcc. > BUT there still is an ABI difference when -tailcallopt is enabled. > > So in cases where a library would be compiled with -tailcallopt > enabled and a the program using the library would be compiled without > -tailcallopt all hell would break loose. After sleeping on it, I think that this is actually ok. We reserve the right to change the 'fastcc' ABI across LLVM releases anyway, which means that it isn't a stable thing that people can depend on. The optimizers only introduce it when it knows all callers of a function, thus it should be safe to do whatever we want within a model, so long as it is consistent within that module. Front-end authors that are using this should know that -tailcallopt affects the fastcc ABI and not use it if possible. However, isn't the plan to eventually remove -tailcallopt, enabling it all the time? -Chris From clattner at apple.com Mon Sep 22 10:51:21 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 22 Sep 2008 08:51:21 -0700 Subject: [llvm-commits] [llvm] r56337 - in /llvm/trunk: test/Analysis/CallGraph/2008-09-09-DirectCall.ll test/Analysis/CallGraph/2008-09-09-UsedByGlobal.ll test/Other/2002-01-31-CallGraph.ll tools/opt/AnalysisWrappers.cpp In-Reply-To: <200809221646.39541.baldrick@free.fr> References: <200809190757.m8J7vA0C007167@zion.cs.uiuc.edu> <0EE8C571-DA8D-4C9A-BE3F-F63486A77CB8@apple.com> <200809221646.39541.baldrick@free.fr> Message-ID: On Sep 22, 2008, at 7:46 AM, Duncan Sands wrote: > Hi Devang, > >> How about renaming -callgraph as -dump-callgraph ? > > opt has the following options that print info. > It seems a bit of a mess. What do you think of the following changes: Works for me! -Chris > > > -callgraph => print-callgraph > -callscc => print-callgraph-sccs > -cfgscc => print-cfg-sccs > -externalfnconstants => print-externalfnconstants > -print => print-function > -print-alias-sets (no change) > -print-callgraph => dot-callgraph > -print-cfg => dot-cfg > -print-cfg-only => dot-cfg-only > -print-dom-info (no change) > -printm => print-module > -printusedtypes => print-used-types > > ? > > Ciao, > > Duncan. > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From arnold.schwaighofer at gmail.com Mon Sep 22 11:20:13 2008 From: arnold.schwaighofer at gmail.com (Arnold Schwaighofer) Date: Mon, 22 Sep 2008 18:20:13 +0200 Subject: [llvm-commits] [llvm] r55807 - in /llvm/trunk: lib/Target/X86/X86CallingConv.td lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/2007-08-13-SpillerReuse.ll test/CodeGen/X86/2008-02-22-ReMatBug.ll test/CodeGen/X86/coalescer-commute3.ll test/Cod In-Reply-To: References: Message-ID: On Mon, Sep 22, 2008 at 5:50 PM, Chris Lattner wrote: >> So in cases where a library would be compiled with -tailcallopt >> enabled and a the program using the library would be compiled without >> -tailcallopt all hell would break loose. > > After sleeping on it, I think that this is actually ok. We reserve > the right to change the 'fastcc' ABI across LLVM releases anyway, > which means that it isn't a stable thing that people can depend on. > The optimizers only introduce it when it knows all callers of a > function, thus it should be safe to do whatever we want within a > model, so long as it is consistent within that module. Yes after thinking about it i remembered that i brought this problem up when i first introduced -tailcallopt and something along the lines of the above was the conclusion. > Front-end authors that are using this should know that -tailcallopt > affects the fastcc ABI and not use it if possible. Yes maybe i should add this somewhere to the documentation. might be a good place. Stating something along the lines: NOTE: If -tailcallopt is enabled the ABI of fastcc changes. Modules compiled with -tailcallopt will not work together with modules compiled without it. > However, isn't the plan to eventually remove -tailcallopt, enabling it > all the time? The last time (a while ago :) i checked (by running the testsuite) the performance was worse. There could be 4 reasons. 1.) fastcc + -tailcallopt results in an additional 'subl %esp ncallee_pops_arg_cnt' after every call site. (if you have a sequence of tailcalls this is not bad since you pay only for the first call, but if all calls are normal calls this might get expensive) 2.) fastcc + -tailcallopt passed no arguments in registers while fastcc without -tailcallopt enabled did 3.) due to lowering of arguments onto the callers arguments additional moves to the stack might be introduced. 4.) something else i have not thought of ;) When i did the performance testing i tried another version where only sibling tail calls were optimized so i could follow a caller pops arguments convention and performance still was worse compared to when -tailcallopt was disabled. Whether and why i didn't think of 2 and the obvious solution i don't remember. I guess i will do another round of testing. To see what happens now e.g after . regards From evan.cheng at apple.com Mon Sep 22 11:57:11 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 22 Sep 2008 09:57:11 -0700 Subject: [llvm-commits] [llvm] r55807 - in /llvm/trunk: lib/Target/X86/X86CallingConv.td lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/2007-08-13-SpillerReuse.ll test/CodeGen/X86/2008-02-22-ReMatBug.ll test/CodeGen/X86/coalescer-commute3.ll test/Cod In-Reply-To: References: Message-ID: <5EF9AA59-E096-42C0-A0DC-413B15440AFE@apple.com> On Sep 22, 2008, at 9:20 AM, Arnold Schwaighofer wrote: > > >> However, isn't the plan to eventually remove -tailcallopt, enabling >> it >> all the time? > The last time (a while ago :) i checked (by running the testsuite) the > performance was worse. There could be 4 reasons. > 1.) fastcc + -tailcallopt results in an additional 'subl %esp > ncallee_pops_arg_cnt' after every call site. > (if you have a sequence of tailcalls this is not bad since you pay > only for the first call, but if all calls are normal calls this might > get expensive) > 2.) fastcc + -tailcallopt passed no arguments in registers while > fastcc without -tailcallopt enabled did I don't think that was the case. For whatever the reason, fastcc was not passing arguments in registers. I fixed that recently. > > 3.) due to lowering of arguments onto the callers arguments additional > moves to the stack might be introduced. > 4.) something else i have not thought of ;) > > When i did the performance testing i tried another version where only > sibling tail calls were optimized so i could follow a caller pops > arguments convention and performance still was worse compared to when > -tailcallopt was disabled. Whether and why i didn't think of 2 and the > obvious solution i don't remember. I guess i will do another round of > testing. To see what happens now e.g after > . Thanks. Evan > > > regards > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From gohman at apple.com Mon Sep 22 12:05:58 2008 From: gohman at apple.com (Dan Gohman) Date: Mon, 22 Sep 2008 10:05:58 -0700 (PDT) Subject: [llvm-commits] [llvm] r55969 - in /llvm/trunk: docs/LangRef.html include/llvm/Bitcode/LLVMBitCodes.h include/llvm/InstrTypes.h include/llvm/Instructions.h lib/AsmParser/llvmAsmParser.y lib/Bitcode/Reader/BitcodeReader.cpp lib/Bitcode/Writer/BitcodeWriter.cpp lib/VMCore/Verifier.cpp test/Assembler/vbool-cmp.ll test/Assembler/vector-select.ll In-Reply-To: References: <200809090102.m8912lLd009502@zion.cs.uiuc.edu> Message-ID: <43603.76.220.41.203.1222103158.squirrel@webmail.apple.com> On Sun, September 21, 2008 11:26 pm, Chris Lattner wrote: > > On Sep 8, 2008, at 6:02 PM, Dan Gohman wrote: > >> Author: djg >> Date: Mon Sep 8 20:02:47 2008 >> New Revision: 55969 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=55969&view=rev >> Log: >> Extend the vcmp/fcmp LLVM IR instructions to take vectors as arguments >> and, if so, to return a vector of boolean as a result; > > Hi Dan and Preston, > > I thought the idea here was to change vicmp and vfcmp to have this > behavior, not change icmp/fcmp to do this. The problem with changing > icmp/fcmp is that you'll break a lot of assumptions throughout the > optimizer that the result of icmp/fcmp is an i1, and the code to > handle this has already been updated for v*cmp. Hi Chris, Overloading plain icmp/fcmp is consistent with how many other operators are overloaded for vector and scalar. It's a longer-term goal here is to eventually obviate v*cmp. This patch is merely a first step, and a prerequisite for much of the remaining steps. The optimizers can be made to check for i1 when necessary. This was included in the vector comparison plan. None of the LLVM front-ends currently produce vector comparisons, so this doesn't need to be addressed immediately. > >> >>> The FUNC_CODE_INST_VCMP thing is a little counter-intuitive. I guess >>> it's necessary in order to remain compatible with exiting vector >>> FUNC_CODE_INST_CMP usage though, right? >> >> Correct. Since FUNC_CODE_INST_CMP with vector arguments is used for >> the >> vfcmp and vicmp instructions, it was necessary to add >> FUNC_CODE_INST_VCMP to support the vector forms of fcmp/icmp. It would >> probably have made more sense in the bitcode reader/writer to switch >> vicmp/vfcmp to use a newly defined bitcode operator, but I did not >> because it seemed likely that it would break existing code. > > Is there any reason to keep around the old v*cmp behavior of returning > a vector of integers? If not, please remove them (as soon as there > are no regressions from doing this). I don't want to have two > different vector compare implementations floating around. {i,f}cmp are not yet ready to replace v*cmp. Currently, codegen cannot effectively handle vectors of i1 on current targets. The goal is to improve codegen and eventually make v*cmp unnecessary, but it'll take some time, and until then we don't want to pull the rug out from people using v*cmp. > Also, LLVM 2.4 is coming up very soon now, would you be ok with > deferring (and reverting) these changes until after 2.4 branches in a > couple weeks? If you'd prefer to do development on a branch until > then that would be fine of course. I view vector {i,f}cmp support as having relatively low risk, since no front-end or optimizer in tree is producing them. I'd be fine with adding a disclaimer to LangRef, or even removing them from LangRef, to help avert misunderstanding. >> --- llvm/trunk/include/llvm/Bitcode/LLVMBitCodes.h (original) >> +++ llvm/trunk/include/llvm/Bitcode/LLVMBitCodes.h Mon Sep 8 >> 20:02:47 2008 >> @@ -205,7 +205,9 @@ >> // FIXME: Remove GETRESULT in favor of EXTRACTVAL in LLVM 3.0 >> FUNC_CODE_INST_GETRESULT = 25, // GETRESULT: [ty, opval, n] >> FUNC_CODE_INST_EXTRACTVAL = 26, // EXTRACTVAL: [n x operands] >> - FUNC_CODE_INST_INSERTVAL = 27 // INSERTVAL: [n x operands] >> + FUNC_CODE_INST_INSERTVAL = 27, // INSERTVAL: [n x operands] >> + // fcmp/icmp returning vector of Int1Ty, NOT for vicmp/vfcmp >> + FUNC_CODE_INST_VCMP = 28 // VCMP: [opty, opval, >> opval, pred] > > Ewww. I still think that vcmp should change into this behavior, if > there is some reason why this would not work, please pick a better > name than INST_VCMP for this! It's already renamed in TOT :-). Oops, the comment isn't updated, but the code is. I'll fix that. >> --- llvm/trunk/include/llvm/InstrTypes.h (original) >> +++ llvm/trunk/include/llvm/InstrTypes.h Mon Sep 8 20:02:47 2008 >> @@ -18,6 +18,7 @@ >> >> #include "llvm/Instruction.h" >> #include "llvm/OperandTraits.h" >> +#include "llvm/DerivedTypes.h" > > Please move the method out of line, to avoid this #include. Ok. >> @@ -732,6 +733,13 @@ >> static inline bool classof(const Value *V) { >> return isa(V) && classof(cast(V)); >> } >> + /// @brief Create a result type for fcmp/icmp (but not vicmp/vfcmp) >> + static const Type* makeCmpResultType(const Type* opnd_type) { > > Instead of 'makeCmp...' please call this 'getVCmpResultType' or > something like that. We use 'get' for uniqued objects like types. > Assuming that you're going to eliminate vicmp/vfcmp, this should be > removed and you should just change its methods. I'm a little confused here. For "make" vs "get", I agree that "get" might be a little more consistent. As for the insertion of the V, it's not just for vector types. And as for removing it and changing all the methods, it's used in four places, which seems enough to justify having this code refactored out into a helper function. > > Okay, I can't review the rest of this patch without getting more > closure on the direction we're going with the IR. I think that > smooshing this into icmp/fcmp is a real mistake. We should change the > old v[if]cmp instruction to return a vector of bool and leave icmp/ > fcmp alone. What do you guys think? > > If you agree, please revert these patches for now. I disagree. In the short term, we can't simply change v*cmp because that would break existing users, and overloading {i,f}cmp is relatively low-risk. In the long term we don't want comparisons to be inconsistent with the rest of the IR. Dan From evan.cheng at apple.com Mon Sep 22 12:10:30 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 22 Sep 2008 10:10:30 -0700 Subject: [llvm-commits] [llvm] r55807 - in /llvm/trunk: lib/Target/X86/X86CallingConv.td lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/2007-08-13-SpillerReuse.ll test/CodeGen/X86/2008-02-22-ReMatBug.ll test/CodeGen/X86/coalescer-commute3.ll test/CodeGen/X86/combine-lds.ll test/CodeGen/X86/fastcc.ll In-Reply-To: References: <200809042259.m84MxxkM017095@zion.cs.uiuc.edu> <484E2891-5028-440E-9C25-875007E6FC66@apple.com> <4CA8151C-767A-4CE9-B712-0DDDB11F2217@apple.com> Message-ID: On Sep 22, 2008, at 8:43 AM, Chris Lattner wrote: > > On Sep 21, 2008, at 11:30 PM, Evan Cheng wrote: > >> Secondly, it's not clear to me why the integer registers have to be >> marked inreg to be passed in registers (only EAX, EDX, what's the >> 3rd). Arnold, any ideas? > > I thought that this was how the normal x86-32 calling conv worked: > Integer values are passed on the stack unless -mregparm (or > attribute) is used, which tags the arguments with 'inreg' Tailcall cc is based on fastcc, no? Is it not possible to pass arguments in registers for tailcalls? Evan > > > -Chris From evan.cheng at apple.com Mon Sep 22 12:10:27 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 22 Sep 2008 10:10:27 -0700 Subject: [llvm-commits] [llvm] r56326 - in /llvm/trunk: include/llvm/CodeGen/LiveInterval.h include/llvm/CodeGen/LiveIntervalAnalysis.h lib/CodeGen/LiveInterval.cpp lib/CodeGen/LiveIntervalAnalysis.cpp lib/CodeGen/RegAllocLinearScan.cpp In-Reply-To: <195CE7BA-AB94-40AC-B4E6-EB01AC814EE6@apple.com> References: <200809190102.m8J12ZW2019167@zion.cs.uiuc.edu> <51666910-CAA2-47A5-9F26-809138EE0E5F@apple.com> <10574389-E3FC-4024-AD0D-A462B01F39B4@apple.com> <5C7E7977-A85C-44DB-8D61-5A8AF02E9C6A@apple.com> <21171FE7-D099-4281-B86A-F0944DD07C4B@apple.com> <195CE7BA-AB94-40AC-B4E6-EB01AC814EE6@apple.com> Message-ID: <5DFE9C90-C5BF-4A4C-B153-931CE13CECCE@apple.com> On Sep 21, 2008, at 6:07 PM, Chris Lattner wrote: > On Sep 19, 2008, at 11:26 AM, Dale Johannesen wrote: >>>> On Sep 19, 2008, at 10:48 AMPDT, Evan Cheng wrote: >>>>>> >>>>>> float weight; // weight of this interval >>>>>> + bool isEarlyClobber; >>>>>> + bool overlapsEarlyClobber; >>>>> >>>>> Hi Dale, >>>>> >>>>> I don't think we want two bits. I'd rather go with one bit and >>>>> have >>>>> register allocator look at both use and def operands. What do you >>>>> think? >>>> >>>> The comment explains why I don't want to do this: >>> >>> Sorry, I don't follow. Can you provide an example? >> >> void foo (int x, int y) { >> int z=x+y; >> int w=x+y; >> int t; >> asm volatile ("%0 %1 %2" : "=&r"(t) : "r"(z), "r"(w)); >> } >> >> %1 and %2 can share a register, but if there is no way to distinguish >> between earlyclobber and overlaps-earlyclobber, we can't do this. >> In theory this is a matter of correctness, it is possible to >> construct >> cases where you run out of registers if you don't share. > > I don't get this at all. How can a *live interval* be an > earlyclobber? It seems that the easy and natural way to model this is > that the def starts one notch earlier in the use slot of an > instruction, instead of it's normal place (the def slot). > > In other words, I don't understand why this needs to be modeled > explicitly in live intervals, the construction of live intervals > should just handle the early clobber def as starting one slot early. As I said in another email, that's the right solution except it breaks liveintervalanalysis and coalescer assumptions. It's possible to try that approach but we don't have enough test coverage for early clobber. Evan > > > -Chris > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From dalej at apple.com Mon Sep 22 12:13:42 2008 From: dalej at apple.com (Dale Johannesen) Date: Mon, 22 Sep 2008 10:13:42 -0700 Subject: [llvm-commits] [llvm] r55973 - in /llvm/trunk: include/llvm/Target/TargetAsmInfo.h lib/CodeGen/AsmPrinter/AsmPrinter.cpp lib/Target/ARM/ARMTargetAsmInfo.cpp lib/Target/PowerPC/PPCTargetAsmInfo.cpp lib/Target/TargetAsmInfo.cpp lib/Target/X86/X86Ta In-Reply-To: <2A05C955-ABA9-4034-A828-BA867682CF6F@apple.com> References: <7461877A-130F-4172-A3B7-D606E513FBA0@apple.com> <2A05C955-ABA9-4034-A828-BA867682CF6F@apple.com> Message-ID: On Sep 21, 2008, at 12:00 PMPDT, Chris Lattner wrote: > On Sep 9, 2008, at 11:19 AM, Dale Johannesen wrote: >> On Sep 9, 2008, at 1:02 AMPDT, Anton Korobeynikov wrote: >>> Hi, Dale >>> >>>> the magic 'l' prefix for symbols on Darwin which are >>>> to be passed through the assembler, then removed at >>>> linktime (previously all references to this had been >>>> hidden in the ObjC FE code, oh well). >>> Sorry for bothering you again, but changing semantics of llvm.used >>> in >>> such target- and language- specific way is a bit... uhm... >>> questionable. >> >> The underlying problem is that two different characteristics are >> involved: "the compiler must not delete this symbol", and "the >> compiler must emit something special to affect assembly- or link- >> time >> behavior". Currently both these key off llvm.used, which is not so >> good because they are not the same thing and do not always apply to >> the same symbols. I have been patching the existing mechanism to >> make >> it work, but I could be persuaded that a new mechanism is better. > > Ok, it sounds like overloading llvm.used like this is the problem. > Maybe the issues is that we need two different "used" lists? One that > is "must be in the assembler output" and "one that must be in the > linker output". The current used list would be the later, and ObjC > could use the former? Two lists would probably be a better design, although the semantics you give here are not right. At the moment, everything works in this area, so it isn't urgent. From clattner at apple.com Mon Sep 22 12:19:03 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 22 Sep 2008 10:19:03 -0700 Subject: [llvm-commits] [llvm] r56326 - in /llvm/trunk: include/llvm/CodeGen/LiveInterval.h include/llvm/CodeGen/LiveIntervalAnalysis.h lib/CodeGen/LiveInterval.cpp lib/CodeGen/LiveIntervalAnalysis.cpp lib/CodeGen/RegAllocLinearScan.cpp In-Reply-To: <5DFE9C90-C5BF-4A4C-B153-931CE13CECCE@apple.com> References: <200809190102.m8J12ZW2019167@zion.cs.uiuc.edu> <51666910-CAA2-47A5-9F26-809138EE0E5F@apple.com> <10574389-E3FC-4024-AD0D-A462B01F39B4@apple.com> <5C7E7977-A85C-44DB-8D61-5A8AF02E9C6A@apple.com> <21171FE7-D099-4281-B86A-F0944DD07C4B@apple.com> <195CE7BA-AB94-40AC-B4E6-EB01AC814EE6@apple.com> <5DFE9C90-C5BF-4A4C-B153-931CE13CECCE@apple.com> Message-ID: <82130F26-42EC-4B2C-BD9D-8E270AE8D46B@apple.com> On Sep 22, 2008, at 10:10 AM, Evan Cheng wrote: >>> %1 and %2 can share a register, but if there is no way to >>> distinguish >>> between earlyclobber and overlaps-earlyclobber, we can't do this. >>> In theory this is a matter of correctness, it is possible to >>> construct >>> cases where you run out of registers if you don't share. >> >> I don't get this at all. How can a *live interval* be an >> earlyclobber? It seems that the easy and natural way to model this >> is >> that the def starts one notch earlier in the use slot of an >> instruction, instead of it's normal place (the def slot). >> >> In other words, I don't understand why this needs to be modeled >> explicitly in live intervals, the construction of live intervals >> should just handle the early clobber def as starting one slot early. > > As I said in another email, that's the right solution except it breaks > liveintervalanalysis and coalescer assumptions. Ok, which assumptions? Can you please point out an example in the code? > It's possible to try > that approach but we don't have enough test coverage for early > clobber. We actually have quite a bit of code that uses earlyclobber asms (and have even found bugs in apps that didn't use earlyclobber where it was supposed to), it is just that they are mostly correctly handled by the hacky code in sdisel. Once that code is removed, early clobber support will start getting more testing. -Chris From dalej at apple.com Mon Sep 22 12:21:38 2008 From: dalej at apple.com (Dale Johannesen) Date: Mon, 22 Sep 2008 10:21:38 -0700 Subject: [llvm-commits] [llvm-gcc-4.2] r55650 - /llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp In-Reply-To: <2ABEF97F-1856-4090-B2C8-BE9EC57B2A0E@apple.com> References: <200809022118.m82LIJeg019335@zion.cs.uiuc.edu> <2ABEF97F-1856-4090-B2C8-BE9EC57B2A0E@apple.com> Message-ID: <295D58A1-2BF8-4B8B-8E3C-C4660992F2F4@apple.com> On Sep 21, 2008, at 12:17 PMPDT, Chris Lattner wrote: > On Sep 2, 2008, at 2:18 PM, Dale Johannesen wrote: >> URL: http://llvm.org/viewvc/llvm-project?rev=55650&view=rev >> Log: >> Don't convert atomics that aren't supported by the target. >> This gets us undefined functions at linktime instead of >> crashes in llvm, which is what gcc does. > > Hi Dale, > >> +++ llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp Tue Sep 2 16:18:19 2008 >> @@ -4590,82 +4590,113 @@ >> return true; >> } >> case BUILT_IN_BOOL_COMPARE_AND_SWAP_8: { >> +#if defined(TARGET_POWERPC) >> + if (!TARGET_64BIT) >> + return false; >> +#endif >> Result = BuildCmpAndSwapAtomicBuiltin(exp, >> long_long_unsigned_type_node, >> true); > > llvm-convert.cpp is target independent code. No, it's not; there's lots of #ifdef TARGET_LLVM's in here. (If you're saying it's not target-dependent because it's using some abstraction rather than TARGET_POWERPC, I strongly disagree.) > Checking for > TARGET_POWERPC here is not right. That may be, but I didn't introduce the target dependency; this whole block is wrapped in #if defined(TARGET_ALPHA) || defined(TARGET_386) || defined(TARGET_POWERPC) > Why not just check TARGET_64BIT or > something like that? Does this happen on x86-32 as well? If not, > maybe there some be some new LLVM_BUILTIN_ATOMIC_OK(...) macro, which > PPC defines. Implementing 64-bit atomic intrinsics on ppc32 makes no sense, because there is no hardware 64-bit atomic operation; these cannot work. In contrast, there is a 64-bit atomic operation on x86-32, although I haven't hooked it up yet. From dalej at apple.com Mon Sep 22 12:26:33 2008 From: dalej at apple.com (Dale Johannesen) Date: Mon, 22 Sep 2008 10:26:33 -0700 Subject: [llvm-commits] [llvm] r56326 - in /llvm/trunk: include/llvm/CodeGen/LiveInterval.h include/llvm/CodeGen/LiveIntervalAnalysis.h lib/CodeGen/LiveInterval.cpp lib/CodeGen/LiveIntervalAnalysis.cpp lib/CodeGen/RegAllocLinearScan.cpp In-Reply-To: <195CE7BA-AB94-40AC-B4E6-EB01AC814EE6@apple.com> References: <200809190102.m8J12ZW2019167@zion.cs.uiuc.edu> <51666910-CAA2-47A5-9F26-809138EE0E5F@apple.com> <10574389-E3FC-4024-AD0D-A462B01F39B4@apple.com> <5C7E7977-A85C-44DB-8D61-5A8AF02E9C6A@apple.com> <21171FE7-D099-4281-B86A-F0944DD07C4B@apple.com> <195CE7BA-AB94-40AC-B4E6-EB01AC814EE6@apple.com> Message-ID: <784F5EFD-0E3E-4B44-9C61-068B330BB066@apple.com> On Sep 21, 2008, at 6:07 PMPDT, Chris Lattner wrote: > > In other words, I don't understand why this needs to be modeled > explicitly in live intervals, the construction of live intervals > should just handle the early clobber def as starting one slot early. That was my first reaction but Evan was strongly of the opinion this would not work. I see you've been discussing details with him, let me know what you come up with... From evan.cheng at apple.com Mon Sep 22 12:28:04 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 22 Sep 2008 10:28:04 -0700 Subject: [llvm-commits] [llvm] r56384 - in /llvm/trunk/lib/CodeGen: RegAllocLinearScan.cpp SimpleRegisterCoalescing.cpp In-Reply-To: <73CDDC9A-1C75-4A15-9931-12DDC51EABCB@apple.com> References: <200809200203.m8K234YA013252@zion.cs.uiuc.edu> <4F71A860-E342-4A07-8211-0A59A1AA154D@apple.com> <8D81D6DA-8289-49E2-B352-53C6C313FDA8@apple.com> <33791BFC-A09D-43EB-B4D0-6582A9243EED@apple.com> <6AABEF56-39B2-4D47-8928-7FC4AC7AB61B@apple.com> <73CDDC9A-1C75-4A15-9931-12DDC51EABCB@apple.com> Message-ID: On Sep 22, 2008, at 8:45 AM, Chris Lattner wrote: > On Sep 21, 2008, at 11:52 PM, Evan Cheng wrote: >> On Sep 21, 2008, at 11:19 PM, Chris Lattner wrote: >>> On Sep 21, 2008, at 11:17 PM, Evan Cheng wrote: >>>>>> While that's the correct approach, it breaks all kinds of >>>>>> assumptions >>>>>> in liveintervals and the coalescer. It will make the problem much >>>>>> more >>>>>> complicated. I don't think it's worth the effort. >>>>> >>>>> What sorts of assumptions? >>>> >>>> That use must be 1 cycle after instruction cycle, def must be 2 >>>> cycles >>>> after it. >>> >>> What code makes this sort of assumption? It seems fragile. >> >> It's all over the place in coalescer. I'd prefer to fix it only when >> it's necessary. Not for early clobber. > > Can you give me an example? It sounds like these sorts of assumptions > are exactly what we want: you can only coalesce a def/use of a copy if > the live ranges exactly line up. Overlapping by one slot is a *good* > thing because we want to prevent coalescing. e.g. // Figure out the value # from the RHS. LHSValsDefinedFromRHS[VNI]=RHS.getLiveRangeContaining(VNI- >def-1)->valno; Ok, so most of the assertions are for copies: LiveInterval::iterator BLR = IntB.FindLiveRangeContaining(CopyIdx); if (BLR == IntB.end()) // Should never happen! return false; VNInfo *BValNo = BLR->valno; // Get the location that B is defined at. Two options: either this value has // an unknown definition point or it is defined at CopyIdx. If unknown, we // can't process it. if (!BValNo->copy) return false; assert(BValNo->def == CopyIdx && "Copy doesn't define the value?"); But it is possible modeling the def this way will *just work*. I doubt it, but it's worth experimenting. > > >>>>> Then you'd have to mark $out0 as being an early clobber, because >>>>> it >>>>> is >>>>> stored to before $in2 is read. >>>> >>>> Ewwww. >>> >>> Eww what? You don't like asms with multiple instructions? Or you >>> prefer CPUs that have instructions that would require this? ;-) >> >> Ewww multi- instruction asm with this horribleness. >> >> Some in-order execution cpu's may require this. Usually it would >> require HW bypass for reads to completed early enough for def to >> target the same registers. It's quite common for some instructions to >> not have the benefit of bypass in some in-order machines. > > Can earlyclobber operands be used to model the armv4 "mul" register > weirdness where the input and output regs can't be the same? We could, but the correct way to model it is to push the use down one cycle, not def up one cycle. The problem with early clobber is the def cannot overlap any of the uses (both Rm and Rs). In the ARM mul case, the def cannot overlap Rm only. Evan > > > -Chris > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From clattner at apple.com Mon Sep 22 12:38:16 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 22 Sep 2008 10:38:16 -0700 Subject: [llvm-commits] [llvm] r56384 - in /llvm/trunk/lib/CodeGen: RegAllocLinearScan.cpp SimpleRegisterCoalescing.cpp In-Reply-To: References: <200809200203.m8K234YA013252@zion.cs.uiuc.edu> <4F71A860-E342-4A07-8211-0A59A1AA154D@apple.com> <8D81D6DA-8289-49E2-B352-53C6C313FDA8@apple.com> <33791BFC-A09D-43EB-B4D0-6582A9243EED@apple.com> <6AABEF56-39B2-4D47-8928-7FC4AC7AB61B@apple.com> <73CDDC9A-1C75-4A15-9931-12DDC51EABCB@apple.com> Message-ID: On Sep 22, 2008, at 10:28 AM, Evan Cheng wrote: >> Can you give me an example? It sounds like these sorts of >> assumptions >> are exactly what we want: you can only coalesce a def/use of a copy >> if >> the live ranges exactly line up. Overlapping by one slot is a *good* >> thing because we want to prevent coalescing. > > e.g. > // Figure out the value # from the RHS. > LHSValsDefinedFromRHS[VNI]=RHS.getLiveRangeContaining(VNI- >> def-1)->valno; > > Ok, so most of the assertions are for copies: > But it is possible modeling the def this way will *just work*. I doubt > it, but it's worth experimenting. I would strongly prefer this. Even if there are cases that don't "just work", I think this is the correct way to model it, and the right long-term answer. >> Can earlyclobber operands be used to model the armv4 "mul" register >> weirdness where the input and output regs can't be the same? > > We could, but the correct way to model it is to push the use down one > cycle, not def up one cycle. The problem with early clobber is the def > cannot overlap any of the uses (both Rm and Rs). In the ARM mul case, > the def cannot overlap Rm only. Sure, I agree with that. This is also true of most inline asms with multiple instructions (like the example I gave). Using earlyclobber should be a conservative but correct solution (and much better than using the 'multiply fixer' pass that used to exist). This would also make it easier to test that earlyclobber is working right (multiplies are more frequent than & in asms), which is why I brought it up. :) -Chris From dalej at apple.com Mon Sep 22 12:39:07 2008 From: dalej at apple.com (Dale Johannesen) Date: Mon, 22 Sep 2008 10:39:07 -0700 Subject: [llvm-commits] [llvm] r55781 - /llvm/trunk/lib/Transforms/Scalar/SimplifyLibCalls.cpp In-Reply-To: <7C829F8E-2755-408C-986D-3545AFDEBF80@apple.com> References: <200809041830.m84IUmxP007821@zion.cs.uiuc.edu> <7C829F8E-2755-408C-986D-3545AFDEBF80@apple.com> Message-ID: On Sep 21, 2008, at 12:42 PMPDT, Chris Lattner wrote: > > On Sep 4, 2008, at 11:30 AM, Dale Johannesen wrote: > >> Author: johannes >> Date: Thu Sep 4 13:30:46 2008 >> New Revision: 55781 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=55781&view=rev >> Log: >> Add intrinsic forms of pow and exp2. The non-intrinsic >> forms remain to handle older IR files, but will go away soon. > > You want to remove handling of "powf" and only handle > "llvm.pow.f32"? Why? > > -Chris Because I don't think the BE should be sensitive to the source language. >> That said, I think it is useful to distinguish between >> SimplifyLibcalls (SLC) and the rest of the compiler. > > Yes, SLC is specific to code that is using the standard C library. > If you were writing a compiler for some language which had 'sin' > mean something unusual, you'd just not run it. I don't think this makes sense. What about languages that have some of the standard C functions but not all of them? This code should be language-independent, with any semantic information (such as errno usage) encoded in the intrinisic; then the BE can apply semantics appropriately. (This, rarely enough, is a case where gcc got the design right.) From clattner at apple.com Mon Sep 22 12:45:34 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 22 Sep 2008 10:45:34 -0700 Subject: [llvm-commits] [llvm] r56384 - in /llvm/trunk/lib/CodeGen: RegAllocLinearScan.cpp SimpleRegisterCoalescing.cpp In-Reply-To: References: <200809200203.m8K234YA013252@zion.cs.uiuc.edu> <4F71A860-E342-4A07-8211-0A59A1AA154D@apple.com> <8D81D6DA-8289-49E2-B352-53C6C313FDA8@apple.com> <33791BFC-A09D-43EB-B4D0-6582A9243EED@apple.com> <6AABEF56-39B2-4D47-8928-7FC4AC7AB61B@apple.com> <73CDDC9A-1C75-4A15-9931-12DDC51EABCB@apple.com> Message-ID: <8B6A9F9F-E41A-48A8-BCD4-E173DA07841C@apple.com> On Sep 22, 2008, at 10:38 AM, Chris Lattner wrote: >>> Can earlyclobber operands be used to model the armv4 "mul" register >>> weirdness where the input and output regs can't be the same? >> >> We could, but the correct way to model it is to push the use down one >> cycle, not def up one cycle. The problem with early clobber is the >> def >> cannot overlap any of the uses (both Rm and Rs). In the ARM mul case, >> the def cannot overlap Rm only. > > Sure, I agree with that. This is also true of most inline asms with > multiple instructions (like the example I gave). Using earlyclobber > should be a conservative but correct solution (and much better than > using the 'multiply fixer' pass that used to exist). > > This would also make it easier to test that earlyclobber is working > right (multiplies are more frequent than & in asms), which is why I > brought it up. :) Also, to be perfectly clear, the testing is pretty easy (doesn't rely on assembler support): just add asserts to the asmprinter that the result isn't the same as any output. Then just build llvm-test with armv4 and see if any asserts come out. If not, declare that earlyclobber works ;-) -Chris From evan.cheng at apple.com Mon Sep 22 12:46:06 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 22 Sep 2008 10:46:06 -0700 Subject: [llvm-commits] [llvm] r56384 - in /llvm/trunk/lib/CodeGen: RegAllocLinearScan.cpp SimpleRegisterCoalescing.cpp In-Reply-To: References: <200809200203.m8K234YA013252@zion.cs.uiuc.edu> <4F71A860-E342-4A07-8211-0A59A1AA154D@apple.com> <8D81D6DA-8289-49E2-B352-53C6C313FDA8@apple.com> <33791BFC-A09D-43EB-B4D0-6582A9243EED@apple.com> <6AABEF56-39B2-4D47-8928-7FC4AC7AB61B@apple.com> <73CDDC9A-1C75-4A15-9931-12DDC51EABCB@apple.com> Message-ID: <99141E76-1A5C-4852-B1B5-7053DA9B02D5@apple.com> On Sep 22, 2008, at 10:38 AM, Chris Lattner wrote: > On Sep 22, 2008, at 10:28 AM, Evan Cheng wrote: >>> Can you give me an example? It sounds like these sorts of >>> assumptions >>> are exactly what we want: you can only coalesce a def/use of a copy >>> if >>> the live ranges exactly line up. Overlapping by one slot is a >>> *good* >>> thing because we want to prevent coalescing. >> >> e.g. >> // Figure out the value # from the RHS. >> LHSValsDefinedFromRHS[VNI]=RHS.getLiveRangeContaining(VNI- >>> def-1)->valno; >> >> Ok, so most of the assertions are for copies: >> But it is possible modeling the def this way will *just work*. I >> doubt >> it, but it's worth experimenting. > > I would strongly prefer this. Even if there are cases that don't > "just work", I think this is the correct way to model it, and the > right long-term answer. Ok fine. Sorry for being overly careful when it comes to the coalescer. Owen, can your liveintervals renumbering work be impacted? i.e. Does it assume def must be one cycle before use? > > >>> Can earlyclobber operands be used to model the armv4 "mul" register >>> weirdness where the input and output regs can't be the same? >> >> We could, but the correct way to model it is to push the use down one >> cycle, not def up one cycle. The problem with early clobber is the >> def >> cannot overlap any of the uses (both Rm and Rs). In the ARM mul case, >> the def cannot overlap Rm only. > > Sure, I agree with that. This is also true of most inline asms with > multiple instructions (like the example I gave). Using earlyclobber > should be a conservative but correct solution (and much better than > using the 'multiply fixer' pass that used to exist). > > This would also make it easier to test that earlyclobber is working > right (multiplies are more frequent than & in asms), which is why I > brought it up. :) That will require some minor tblgen and TargetInstrDesc changes. If someone want to do that, sure. Evan > > > -Chris > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From clattner at apple.com Mon Sep 22 12:48:13 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 22 Sep 2008 10:48:13 -0700 Subject: [llvm-commits] [llvm] r55781 - /llvm/trunk/lib/Transforms/Scalar/SimplifyLibCalls.cpp In-Reply-To: References: <200809041830.m84IUmxP007821@zion.cs.uiuc.edu> <7C829F8E-2755-408C-986D-3545AFDEBF80@apple.com> Message-ID: On Sep 22, 2008, at 10:39 AM, Dale Johannesen wrote: >> On Sep 4, 2008, at 11:30 AM, Dale Johannesen wrote: >>> Author: johannes >>> Date: Thu Sep 4 13:30:46 2008 >>> New Revision: 55781 >>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=55781&view=rev >>> Log: >>> Add intrinsic forms of pow and exp2. The non-intrinsic >>> forms remain to handle older IR files, but will go away soon. >> >> You want to remove handling of "powf" and only handle >> "llvm.pow.f32"? Why? >> >> -Chris > > Because I don't think the BE should be sensitive to the source > language. You don't think that LLVM should allow source-language-specific passes? >>> That said, I think it is useful to distinguish between >>> SimplifyLibcalls (SLC) and the rest of the compiler. >> >> Yes, SLC is specific to code that is using the standard C library. >> If you were writing a compiler for some language which had 'sin' >> mean something unusual, you'd just not run it. > > I don't think this makes sense. What about languages that have some > of the standard C functions but not all of them? This doesn't have anything to do with the backend knowing about source language: we already have this problem with GCC and C. GCC supports - fno-builtin-foo. We need a better way to model this, and that way may be to add intrinsics for everything that the optimizer looks at, but there are other options. > This code should be language-independent, with any semantic > information (such as errno usage) encoded in the intrinisic; then > the BE can apply semantics appropriately. (This, rarely enough, is > a case where gcc got the design right.) I agree that the IR should capture errno assumptions/behavior. For more of these functions, that can be done with readnone/readonly. -Chris From dpatel at apple.com Mon Sep 22 12:54:54 2008 From: dpatel at apple.com (Devang Patel) Date: Mon, 22 Sep 2008 10:54:54 -0700 Subject: [llvm-commits] [llvm] r55794 - in /llvm/trunk/lib/Target/X86/AsmPrinter: X86ATTAsmPrinter.cpp X86IntelAsmPrinter.cpp In-Reply-To: References: <200809042103.m84L3fBo012834@zion.cs.uiuc.edu> <200809051000.23606.baldrick@free.fr> Message-ID: <0BF26B53-70FC-4345-9713-E6D9E331E2AF@apple.com> On Sep 21, 2008, at 12:45 PM, Chris Lattner wrote: > > On Sep 5, 2008, at 1:00 AM, Duncan Sands wrote: > >> Hi Devang, >> >>> unsigned FnAlign = OptimizeForSize ? 1 : 4; >>> + if (FnAlign == 4 && (F->getNotes() & FN_NOTE_OptimizeForSize)) >>> + FnAlign = 1; >> >> There's no point in testing that FnAlign == 4 here. I appreciate >> that you may be trying for a small speedup, but it just makes the >> code more fragile. > > Devang, ping. Better yet, this should be: > > unsigned FnAlign = (OptimizeForSize || F- > >hasNote(FN_NOTE_OptimizeForSize)) ? 1 : 4; > > and eventually OptimizeForSize goes away. yes. I am just going to remove OptimizeForSize flag. - Devang From dalej at apple.com Mon Sep 22 13:02:06 2008 From: dalej at apple.com (Dale Johannesen) Date: Mon, 22 Sep 2008 11:02:06 -0700 Subject: [llvm-commits] [llvm] r55781 - /llvm/trunk/lib/Transforms/Scalar/SimplifyLibCalls.cpp In-Reply-To: References: <200809041830.m84IUmxP007821@zion.cs.uiuc.edu> <7C829F8E-2755-408C-986D-3545AFDEBF80@apple.com> Message-ID: <944A649C-5E3A-4E9C-9A71-830C9E64E471@apple.com> On Sep 22, 2008, at 10:48 AMPDT, Chris Lattner wrote: > On Sep 22, 2008, at 10:39 AM, Dale Johannesen wrote: >>> On Sep 4, 2008, at 11:30 AM, Dale Johannesen wrote: >>>> Author: johannes >>>> Date: Thu Sep 4 13:30:46 2008 >>>> New Revision: 55781 >>>> >>>> URL: http://llvm.org/viewvc/llvm-project?rev=55781&view=rev >>>> Log: >>>> Add intrinsic forms of pow and exp2. The non-intrinsic >>>> forms remain to handle older IR files, but will go away soon. >>> >>> You want to remove handling of "powf" and only handle >>> "llvm.pow.f32"? Why? >>> >>> -Chris >> >> Because I don't think the BE should be sensitive to the source >> language. > > You don't think that LLVM should allow source-language-specific > passes? No. (To be sure, every compiler IR starts out with the goal of keeping language-specific knowledge out of the BE and target-specific knowledge out of the FE, but I'm not sure any succeeds completely. ANDF might have.) >>>> That said, I think it is useful to distinguish between >>>> SimplifyLibcalls (SLC) and the rest of the compiler. >>> >>> Yes, SLC is specific to code that is using the standard C >>> library. If you were writing a compiler for some language which >>> had 'sin' mean something unusual, you'd just not run it. >> >> I don't think this makes sense. What about languages that have >> some of the standard C functions but not all of them? > > This doesn't have anything to do with the backend knowing about > source language: we already have this problem with GCC and C. GCC > supports -fno-builtin-foo. We need a better way to model this, and > that way may be to add intrinsics for everything that the optimizer > looks at, but there are other options. > >> This code should be language-independent, with any semantic >> information (such as errno usage) encoded in the intrinisic; then >> the BE can apply semantics appropriately. (This, rarely enough, >> is a case where gcc got the design right.) > > I agree that the IR should capture errno assumptions/behavior. For > more of these functions, that can be done with readnone/readonly. Actually neither readnone nor readonly does a good job of capturing the semantics of (say) log; we want something in between that means "reads rounding mode but not memory". As discussed elsewhere. From dpatel at apple.com Mon Sep 22 13:02:57 2008 From: dpatel at apple.com (Devang Patel) Date: Mon, 22 Sep 2008 11:02:57 -0700 Subject: [llvm-commits] [llvm] r55673 - in /llvm/trunk: lib/Transforms/IPO/Inliner.cpp test/Transforms/Inline/2008-09-02-AlwaysInline.ll test/Transforms/Inline/2008-09-02-NoInline.ll In-Reply-To: References: <200809022216.m82MGDNg021600@zion.cs.uiuc.edu> <200809030859.25530.baldrick@free.fr> Message-ID: <8A709906-22DF-4CCC-BE36-127F719EE96A@apple.com> On Sep 21, 2008, at 8:36 PM, Chris Lattner wrote: > > On Sep 3, 2008, at 9:41 AM, Devang Patel wrote: > >> >> On Sep 2, 2008, at 11:59 PM, Duncan Sands wrote: >> >>> Hi Devang, >>> >>>> respect inline=never and inline=always notes. >>> >>> what happens if you set inline=always on a function >>> that calls itself? Does the inliner go into an >>> infinite loop? >> >> That'd be a bug. > > Ok, so what happens now? Is that a bug in the current code, or have > you fixed that? The inliner does not inline a call where caller and callee are same. inline=always does not override this behavior. The inliner may decide to not inline due to various reasons : - caller == callee - weak linkage - function takes variable number of args - GCs do not match inline=always does not override these checks. - Devang From dpatel at apple.com Mon Sep 22 13:08:00 2008 From: dpatel at apple.com (Devang Patel) Date: Mon, 22 Sep 2008 11:08:00 -0700 Subject: [llvm-commits] [llvm] r56337 - in /llvm/trunk: test/Analysis/CallGraph/2008-09-09-DirectCall.ll test/Analysis/CallGraph/2008-09-09-UsedByGlobal.ll test/Other/2002-01-31-CallGraph.ll tools/opt/AnalysisWrappers.cpp In-Reply-To: <200809221646.39541.baldrick@free.fr> References: <200809190757.m8J7vA0C007167@zion.cs.uiuc.edu> <0EE8C571-DA8D-4C9A-BE3F-F63486A77CB8@apple.com> <200809221646.39541.baldrick@free.fr> Message-ID: <53FAD328-4886-48CD-952E-60C55E03E29B@apple.com> On Sep 22, 2008, at 7:46 AM, Duncan Sands wrote: > Hi Devang, > >> How about renaming -callgraph as -dump-callgraph ? > > opt has the following options that print info. > > -callgraph - Print a call graph > -callscc - Print SCCs of the Call > Graph > -cfgscc - Print SCCs of each > function CFG > -externalfnconstants - Print external fn > callsites passed constants > -print - Print function to stderr > -print-alias-sets - Alias Set Printer > -print-callgraph - Print Call Graph to 'dot' > file > -print-cfg - Print CFG of function to > 'dot' file > -print-cfg-only - Print CFG of function to > 'dot' file (with no function bodies) > -print-dom-info - Dominator Info Printer > -printm - Print module to stderr > -printusedtypes - Find Used Types > > It seems a bit of a mess. What do you think of the following changes: > > -callgraph => print-callgraph > -callscc => print-callgraph-sccs > -cfgscc => print-cfg-sccs > -externalfnconstants => print-externalfnconstants > -print => print-function > -print-alias-sets (no change) > -print-callgraph => dot-callgraph > -print-cfg => dot-cfg > -print-cfg-only => dot-cfg-only > -print-dom-info (no change) > -printm => print-module > -printusedtypes => print-used-types > > ? Yes, this is better. - Devang From dpatel at apple.com Mon Sep 22 13:17:40 2008 From: dpatel at apple.com (Devang Patel) Date: Mon, 22 Sep 2008 11:17:40 -0700 Subject: [llvm-commits] [llvm] r55638 - /llvm/trunk/include/llvm/Function.h In-Reply-To: References: <200809021833.m82IXtBb013569@zion.cs.uiuc.edu> Message-ID: <690E1C5C-04C8-4030-A740-8E3CE1CDE635@apple.com> On Sep 21, 2008, at 8:40 PM, Chris Lattner wrote: >>> Are we planning >>> to drop "custom" notes? If yes - them now I'm just seeing >>> duplicating >>> existing paramattrs functionality. >> >> paramattrs are associated with parameter, this is associated with the >> definition. Some of the paramattrs can be used with call/invoke >> instructions, e.g. nounwind. Where as notes are never associated with >> call/invoke instruction. > > I guess that I don't understand what you're saying here. Are you > saying that there should be two "namespaces", one for function > attributes and one for arg/retval attributes? Yes. parameter attributes are associated with an arguments. Function note is associated with function definition. > Are you saying that attributes are distinct from notes because > attributes are applied to call sites also? yes, some of the attributes are (e.g. signext) are used in call instruction also. Function notes are never specified at call site. > It seems that function attributes are strictly more general than > notes, why not just add these as attributes? Attributes have to maintaing mapping with respective arguments. Some of the attributes are associated with a return vale. However, some of the attributes, e.g. readonly can easily be converted to a note. We should reserve attributes associated with argument zero as return value specific attributes. I think the two concepts are separate enough to distinguish them at IR level. - Devang From kremenek at apple.com Mon Sep 22 13:19:13 2008 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 22 Sep 2008 18:19:13 -0000 Subject: [llvm-commits] [llvm] r56450 - /llvm/tags/checker/checker-96/ Message-ID: <200809221819.m8MIJDIM028423@zion.cs.uiuc.edu> Author: kremenek Date: Mon Sep 22 13:19:13 2008 New Revision: 56450 URL: http://llvm.org/viewvc/llvm-project?rev=56450&view=rev Log: Tagging checker-96. Added: llvm/tags/checker/checker-96/ - copied from r56449, llvm/trunk/ From evan.cheng at apple.com Mon Sep 22 13:19:24 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 22 Sep 2008 18:19:24 -0000 Subject: [llvm-commits] [llvm] r56452 - /llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp Message-ID: <200809221819.m8MIJPEw028456@zion.cs.uiuc.edu> Author: evancheng Date: Mon Sep 22 13:19:24 2008 New Revision: 56452 URL: http://llvm.org/viewvc/llvm-project?rev=56452&view=rev Log: Per review feedback: Only perform (srl x, (trunc (and y, c))) -> (srl x, (and (trunc y), c)) etc. when both "trunc" and "and" have single uses. Modified: llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp Modified: llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp?rev=56452&r1=56451&r2=56452&view=diff ============================================================================== --- llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp (original) +++ llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp Mon Sep 22 13:19:24 2008 @@ -2312,21 +2312,17 @@ // fold (shl x, (trunc (and y, c))) -> (shl x, (and (trunc y), c)) // iff (trunc c) == c if (N1.getOpcode() == ISD::TRUNCATE && - N1.getOperand(0).getOpcode() == ISD::AND) { + N1.getOperand(0).getOpcode() == ISD::AND && + N1.hasOneUse() && N1.getOperand(0).hasOneUse()) { SDValue N101 = N1.getOperand(0).getOperand(1); - ConstantSDNode *N101C = dyn_cast(N101); - if (N101C) { + if (ConstantSDNode *N101C = dyn_cast(N101)) { MVT TruncVT = N1.getValueType(); - unsigned TruncBitSize = TruncVT.getSizeInBits(); - APInt ShAmt = N101C->getAPIntValue(); - if (ShAmt.trunc(TruncBitSize).getZExtValue() == N101C->getZExtValue()) { - SDValue N100 = N1.getOperand(0).getOperand(0); - return DAG.getNode(ISD::SHL, VT, N0, - DAG.getNode(ISD::AND, TruncVT, - DAG.getNode(ISD::TRUNCATE, TruncVT, N100), - DAG.getConstant(N101C->getZExtValue(), - TruncVT))); - } + SDValue N100 = N1.getOperand(0).getOperand(0); + return DAG.getNode(ISD::SHL, VT, N0, + DAG.getNode(ISD::AND, TruncVT, + DAG.getNode(ISD::TRUNCATE, TruncVT, N100), + DAG.getConstant(N101C->getZExtValue(), + TruncVT))); } } @@ -2444,21 +2440,17 @@ // fold (sra x, (trunc (and y, c))) -> (sra x, (and (trunc y), c)) // iff (trunc c) == c if (N1.getOpcode() == ISD::TRUNCATE && - N1.getOperand(0).getOpcode() == ISD::AND) { + N1.getOperand(0).getOpcode() == ISD::AND && + N1.hasOneUse() && N1.getOperand(0).hasOneUse()) { SDValue N101 = N1.getOperand(0).getOperand(1); - ConstantSDNode *N101C = dyn_cast(N101); - if (N101C) { + if (ConstantSDNode *N101C = dyn_cast(N101)) { MVT TruncVT = N1.getValueType(); - unsigned TruncBitSize = TruncVT.getSizeInBits(); - APInt ShAmt = N101C->getAPIntValue(); - if (ShAmt.trunc(TruncBitSize).getZExtValue() == N101C->getZExtValue()) { - SDValue N100 = N1.getOperand(0).getOperand(0); - return DAG.getNode(ISD::SRA, VT, N0, - DAG.getNode(ISD::AND, TruncVT, - DAG.getNode(ISD::TRUNCATE, TruncVT, N100), - DAG.getConstant(N101C->getZExtValue(), - TruncVT))); - } + SDValue N100 = N1.getOperand(0).getOperand(0); + return DAG.getNode(ISD::SRA, VT, N0, + DAG.getNode(ISD::AND, TruncVT, + DAG.getNode(ISD::TRUNCATE, TruncVT, N100), + DAG.getConstant(N101C->getZExtValue(), + TruncVT))); } } @@ -2565,21 +2557,17 @@ // fold (srl x, (trunc (and y, c))) -> (srl x, (and (trunc y), c)) // iff (trunc c) == c if (N1.getOpcode() == ISD::TRUNCATE && - N1.getOperand(0).getOpcode() == ISD::AND) { + N1.getOperand(0).getOpcode() == ISD::AND && + N1.hasOneUse() && N1.getOperand(0).hasOneUse()) { SDValue N101 = N1.getOperand(0).getOperand(1); - ConstantSDNode *N101C = dyn_cast(N101); - if (N101C) { + if (ConstantSDNode *N101C = dyn_cast(N101)) { MVT TruncVT = N1.getValueType(); - unsigned TruncBitSize = TruncVT.getSizeInBits(); - APInt ShAmt = N101C->getAPIntValue(); - if (ShAmt.trunc(TruncBitSize).getZExtValue() == N101C->getZExtValue()) { - SDValue N100 = N1.getOperand(0).getOperand(0); - return DAG.getNode(ISD::SRL, VT, N0, - DAG.getNode(ISD::AND, TruncVT, - DAG.getNode(ISD::TRUNCATE, TruncVT, N100), - DAG.getConstant(N101C->getZExtValue(), - TruncVT))); - } + SDValue N100 = N1.getOperand(0).getOperand(0); + return DAG.getNode(ISD::SRL, VT, N0, + DAG.getNode(ISD::AND, TruncVT, + DAG.getNode(ISD::TRUNCATE, TruncVT, N100), + DAG.getConstant(N101C->getZExtValue(), + TruncVT))); } } From ofv at wanadoo.es Mon Sep 22 13:21:51 2008 From: ofv at wanadoo.es (Oscar Fuentes) Date: Mon, 22 Sep 2008 18:21:51 -0000 Subject: [llvm-commits] [llvm] r56453 - in /llvm/trunk: CMakeLists.txt cmake/modules/AddLLVM.cmake cmake/modules/AddPartiallyLinkedObject.cmake lib/Target/X86/AsmPrinter/CMakeLists.txt lib/Target/X86/CMakeLists.txt tools/llvm-config/CMakeLists.txt Message-ID: <200809221821.m8MILpC1028583@zion.cs.uiuc.edu> Author: ofv Date: Mon Sep 22 13:21:51 2008 New Revision: 56453 URL: http://llvm.org/viewvc/llvm-project?rev=56453&view=rev Log: CMake build system: support for parallel builds. Modified: llvm/trunk/CMakeLists.txt llvm/trunk/cmake/modules/AddLLVM.cmake llvm/trunk/cmake/modules/AddPartiallyLinkedObject.cmake llvm/trunk/lib/Target/X86/AsmPrinter/CMakeLists.txt llvm/trunk/lib/Target/X86/CMakeLists.txt llvm/trunk/tools/llvm-config/CMakeLists.txt Modified: llvm/trunk/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/CMakeLists.txt?rev=56453&r1=56452&r2=56453&view=diff ============================================================================== --- llvm/trunk/CMakeLists.txt (original) +++ llvm/trunk/CMakeLists.txt Mon Sep 22 13:21:51 2008 @@ -97,6 +97,10 @@ add_subdirectory(lib/Support) add_subdirectory(lib/System) + +# Everything else depends on Support and System: +set(LLVM_COMMON_DEPENDS ${LLVM_COMMON_DEPENDS} ${LLVM_LIBS} ) + add_subdirectory(utils/TableGen) add_custom_command(OUTPUT ${llvm_builded_incs_dir}/Intrinsics.gen @@ -107,6 +111,8 @@ add_custom_target(intrinsics_gen ALL DEPENDS ${llvm_builded_incs_dir}/Intrinsics.gen) +set(LLVM_COMMON_DEPENDS ${LLVM_COMMON_DEPENDS} intrinsics_gen ) + add_subdirectory(lib/VMCore) add_subdirectory(lib/CodeGen) add_subdirectory(lib/CodeGen/SelectionDAG) Modified: llvm/trunk/cmake/modules/AddLLVM.cmake URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/cmake/modules/AddLLVM.cmake?rev=56453&r1=56452&r2=56453&view=diff ============================================================================== --- llvm/trunk/cmake/modules/AddLLVM.cmake (original) +++ llvm/trunk/cmake/modules/AddLLVM.cmake Mon Sep 22 13:21:51 2008 @@ -3,6 +3,10 @@ macro(add_llvm_library name) add_library( ${name} ${ARGN} ) set( llvm_libs ${llvm_libs} ${name} PARENT_SCOPE) + set( llvm_lib_targets ${llvm_lib_targets} ${name} PARENT_SCOPE ) + if( LLVM_COMMON_DEPENDS ) + add_dependencies( ${name} ${LLVM_COMMON_DEPENDS} ) + endif( LLVM_COMMON_DEPENDS ) endmacro(add_llvm_library name) Modified: llvm/trunk/cmake/modules/AddPartiallyLinkedObject.cmake URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/cmake/modules/AddPartiallyLinkedObject.cmake?rev=56453&r1=56452&r2=56453&view=diff ============================================================================== --- llvm/trunk/cmake/modules/AddPartiallyLinkedObject.cmake (original) +++ llvm/trunk/cmake/modules/AddPartiallyLinkedObject.cmake Mon Sep 22 13:21:51 2008 @@ -1,4 +1,13 @@ +macro(target_name_of_partially_linked_object lib var) + if( MSVC ) + set(${var} ${lib}) + else( MSVC ) + set(${var} ${lib}_pll) + endif( MSVC ) +endmacro(target_name_of_partially_linked_object lib var) + + macro(add_partially_linked_object lib) if( MSVC ) add_llvm_library( ${lib} ${ARGN}) @@ -7,6 +16,9 @@ set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/temp_lib) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/temp_lib) add_library( ${lib} STATIC ${ARGN}) + if( LLVM_COMMON_DEPENDS ) + add_dependencies( ${lib} ${LLVM_COMMON_DEPENDS} ) + endif( LLVM_COMMON_DEPENDS ) add_custom_command(OUTPUT ${pll} COMMENT "Building ${lib}.o..." DEPENDS ${lib} @@ -15,7 +27,9 @@ COMMAND ld -r *${CMAKE_CXX_OUTPUT_EXTENSION} -o ${pll} COMMAND rm -f *${CMAKE_CXX_OUTPUT_EXTENSION} ) - add_custom_target(${lib}_pll ALL DEPENDS ${pll}) + target_name_of_partially_linked_object(${lib} tnplo) + add_custom_target(${tnplo} ALL DEPENDS ${pll}) set( llvm_libs ${llvm_libs} ${pll} PARENT_SCOPE) + set( llvm_lib_targets ${llvm_lib_targets} ${tnplo} PARENT_SCOPE ) endif( MSVC ) endmacro(add_partially_linked_object lib) Modified: llvm/trunk/lib/Target/X86/AsmPrinter/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/AsmPrinter/CMakeLists.txt?rev=56453&r1=56452&r2=56453&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/AsmPrinter/CMakeLists.txt (original) +++ llvm/trunk/lib/Target/X86/AsmPrinter/CMakeLists.txt Mon Sep 22 13:21:51 2008 @@ -5,3 +5,7 @@ X86AsmPrinter.cpp X86IntelAsmPrinter.cpp ) + +target_name_of_partially_linked_object(LLVMX86CodeGen n) + +add_dependencies(LLVMX86AsmPrinter ${n}) Modified: llvm/trunk/lib/Target/X86/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/CMakeLists.txt?rev=56453&r1=56452&r2=56453&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/CMakeLists.txt (original) +++ llvm/trunk/lib/Target/X86/CMakeLists.txt Mon Sep 22 13:21:51 2008 @@ -20,7 +20,6 @@ add_custom_target(X86Table_gen echo Tablegenning DEPENDS - ${llvm_builded_incs_dir}/Intrinsics.gen ${CMAKE_CURRENT_BINARY_DIR}/X86GenRegisterInfo.h.inc ${CMAKE_CURRENT_BINARY_DIR}/X86GenRegisterNames.inc ${CMAKE_CURRENT_BINARY_DIR}/X86GenRegisterInfo.inc @@ -34,6 +33,8 @@ ${CMAKE_CURRENT_BINARY_DIR}/X86GenSubtarget.inc ) +add_dependencies(X86Table_gen ${LLVM_COMMON_DEPENDS}) + include_directories(BEFORE ${CMAKE_CURRENT_BINARY_DIR}) add_partially_linked_object(LLVMX86CodeGen Modified: llvm/trunk/tools/llvm-config/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-config/CMakeLists.txt?rev=56453&r1=56452&r2=56453&view=diff ============================================================================== --- llvm/trunk/tools/llvm-config/CMakeLists.txt (original) +++ llvm/trunk/tools/llvm-config/CMakeLists.txt Mon Sep 22 13:21:51 2008 @@ -69,7 +69,6 @@ add_custom_command(OUTPUT ${LIBDEPS_TMP} COMMAND ${PERL_EXECUTABLE} ${LLVM_MAIN_SRC_DIR}/utils/GenLibDeps.pl -flat ${CMAKE_ARCHIVE_OUTPUT_DIRECTORY} > ${LIBDEPS_TMP} - DEPENDS ${llvm_libs} COMMENT "Regenerating ${LIBDEPS_TMP}") add_custom_command(OUTPUT ${LIBDEPS} @@ -99,4 +98,6 @@ ) add_custom_target(llvm-config.target ALL - DEPENDS ${LLVM_CONFIG}) \ No newline at end of file + DEPENDS ${LLVM_CONFIG}) + +add_dependencies(llvm-config.target ${llvm_lib_targets}) From dpatel at apple.com Mon Sep 22 13:21:48 2008 From: dpatel at apple.com (Devang Patel) Date: Mon, 22 Sep 2008 11:21:48 -0700 Subject: [llvm-commits] [llvm-gcc-4.2] r55718 - /llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp In-Reply-To: <4DF68CD0-1A0C-4B54-AE37-0F8D18FDF11D@apple.com> References: <200809032001.m83K1RkI012649@zion.cs.uiuc.edu> <4DF68CD0-1A0C-4B54-AE37-0F8D18FDF11D@apple.com> Message-ID: <7AE2A0A8-5EFC-4559-A100-14B2BB4C89A5@apple.com> On Sep 21, 2008, at 8:43 PM, Chris Lattner wrote: >> + else { >> + // The inliner pass won't be inserted based on command line >> options. >> + // Use AlwaysInliner to handle functions that are marked as >> always_inline. >> + bool NeedAlwaysInliner = false; >> + for (Module::iterator I = TheModule->begin(), E = TheModule- >> >end(); >> + I != E; ++I) >> + if (!I->isDeclaration() && I->getNotes() == >> FN_NOTE_AlwaysInline) { >> + NeedAlwaysInliner = true; >> + break; >> + } >> + if (NeedAlwaysInliner) >> + PM->add(createAlwaysInlinerPass()); > > Please don't do this loop here, just unconditionally add it to the > passmgr. Is there some advantage to checking here (in llvmgcc) > rather than in the pass itself? Only one advantage is a small convenience to llvm developers. When we are using -analyze or -print or intentionally running selected pass for debugging/testing then you do not want PassManager to annoy you. This is not a big deal, and I do not see any advantage for end users. - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20080922/f42cf77f/attachment.html From baldrick at free.fr Mon Sep 22 13:55:43 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 22 Sep 2008 20:55:43 +0200 Subject: [llvm-commits] [llvm] r55781 - /llvm/trunk/lib/Transforms/Scalar/SimplifyLibCalls.cpp In-Reply-To: <944A649C-5E3A-4E9C-9A71-830C9E64E471@apple.com> References: <200809041830.m84IUmxP007821@zion.cs.uiuc.edu> <944A649C-5E3A-4E9C-9A71-830C9E64E471@apple.com> Message-ID: <200809222055.43490.baldrick@free.fr> > Actually neither readnone nor readonly does a good job of capturing > the semantics of (say) log; we want something in between that means > "reads rounding mode but not memory". As discussed elsewhere. And as Chris pointed out somewhere, it's rather pointless to try to get correct rounding mode behaviour for calls to functions like sin & log, when simpler operations like multiplication and division currently don't pay any attention to the rounding mode. So I'm sorry I was so annoying about the rounding mode before :) Ciao, Duncan. From baldrick at free.fr Mon Sep 22 13:58:27 2008 From: baldrick at free.fr (Duncan Sands) Date: Mon, 22 Sep 2008 20:58:27 +0200 Subject: [llvm-commits] =?iso-8859-1?q?=5Bllvm=5D_r55638=09-=09/llvm/trunk?= =?iso-8859-1?q?/include/llvm/Function=2Eh?= In-Reply-To: <690E1C5C-04C8-4030-A740-8E3CE1CDE635@apple.com> References: <200809021833.m82IXtBb013569@zion.cs.uiuc.edu> <690E1C5C-04C8-4030-A740-8E3CE1CDE635@apple.com> Message-ID: <200809222058.28125.baldrick@free.fr> Hi Devang, > Attributes have to maintaing mapping with respective arguments. Some > of the attributes are associated with a return vale. However, some of > the attributes, e.g. readonly can easily be converted to a note. actually it is theoretically useful to be able to specify readonly on a call to a function that is not readonly: it means that this particular call doesn't read memory (presumably because the function is being passed a special value for some parameter) even though general calls to it might. Ciao, Duncan. From ggreif at gmail.com Mon Sep 22 14:42:39 2008 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 22 Sep 2008 19:42:39 -0000 Subject: [llvm-commits] [llvm] r56455 - in /llvm/branches/ggreif/use-diet: include/llvm/Use.h include/llvm/Value.h lib/VMCore/Use.cpp Message-ID: <200809221942.m8MJge3Y031273@zion.cs.uiuc.edu> Author: ggreif Date: Mon Sep 22 14:42:39 2008 New Revision: 56455 URL: http://llvm.org/viewvc/llvm-project?rev=56455&view=rev Log: get rid of most references to Use::Val1 Modified: llvm/branches/ggreif/use-diet/include/llvm/Use.h llvm/branches/ggreif/use-diet/include/llvm/Value.h llvm/branches/ggreif/use-diet/lib/VMCore/Use.cpp Modified: llvm/branches/ggreif/use-diet/include/llvm/Use.h URL: http://llvm.org/viewvc/llvm-project/llvm/branches/ggreif/use-diet/include/llvm/Use.h?rev=56455&r1=56454&r2=56455&view=diff ============================================================================== --- llvm/branches/ggreif/use-diet/include/llvm/Use.h (original) +++ llvm/branches/ggreif/use-diet/include/llvm/Use.h Mon Sep 22 14:42:39 2008 @@ -92,7 +92,7 @@ /// Destructor - Only for zap() inline ~Use() { - if (Val1) removeFromList(); + if (!isNil(Next)) removeFromList(); } /// Default ctor - This leaves the Use completely uninitialized. The only thing @@ -130,7 +130,7 @@ return RHS; } const Use &operator=(const Use &RHS) { - set(RHS.Val1); + set(RHS.get()); return *this; } @@ -141,7 +141,6 @@ ? 0 : stripTag(Next); } private: - Value *Val1; Use *Next, **Prev; void setPrev(Use **NewPrev) { @@ -241,7 +240,7 @@ Value *Use::get() const { return fullStopTagN == extractTag(Next) ? reinterpret_cast(stripTag(Next)) - : (Val1 == getValue() ? Val1 : 0); // should crash if not equal! + : getValue(); } template<> struct simplify_type > { Modified: llvm/branches/ggreif/use-diet/include/llvm/Value.h URL: http://llvm.org/viewvc/llvm-project/llvm/branches/ggreif/use-diet/include/llvm/Value.h?rev=56455&r1=56454&r2=56455&view=diff ============================================================================== --- llvm/branches/ggreif/use-diet/include/llvm/Value.h (original) +++ llvm/branches/ggreif/use-diet/include/llvm/Value.h Mon Sep 22 14:42:39 2008 @@ -233,14 +233,12 @@ } void Use::init(Value *V, User *user) { - Val1 = V; if (V) V->addUse(*this); else Next = nilUse(0); } void Use::set(Value *V) { - if (Val1) removeFromList(); - Val1 = V; + if (isNil(Next)) removeFromList(); if (V) V->addUse(*this); else Next = nilUse(0); } Modified: llvm/branches/ggreif/use-diet/lib/VMCore/Use.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/branches/ggreif/use-diet/lib/VMCore/Use.cpp?rev=56455&r1=56454&r2=56455&view=diff ============================================================================== --- llvm/branches/ggreif/use-diet/lib/VMCore/Use.cpp (original) +++ llvm/branches/ggreif/use-diet/lib/VMCore/Use.cpp Mon Sep 22 14:42:39 2008 @@ -89,7 +89,6 @@ ptrdiff_t Count = Done; while (Start != Stop) { --Stop; - Stop->Val1 = 0; Stop->Next = nilUse(0); if (!Count) { Stop->Prev = reinterpret_cast(Done == 0 ? fullStopTag : stopTag); From dalej at apple.com Mon Sep 22 14:51:58 2008 From: dalej at apple.com (Dale Johannesen) Date: Mon, 22 Sep 2008 19:51:58 -0000 Subject: [llvm-commits] [llvm] r56456 - /llvm/trunk/lib/CodeGen/IntrinsicLowering.cpp Message-ID: <200809221951.m8MJpwZr031588@zion.cs.uiuc.edu> Author: johannes Date: Mon Sep 22 14:51:58 2008 New Revision: 56456 URL: http://llvm.org/viewvc/llvm-project?rev=56456&view=rev Log: Refactor FP intrinisic setup. Per review feedback. Modified: llvm/trunk/lib/CodeGen/IntrinsicLowering.cpp Modified: llvm/trunk/lib/CodeGen/IntrinsicLowering.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/IntrinsicLowering.cpp?rev=56456&r1=56455&r2=56456&view=diff ============================================================================== --- llvm/trunk/lib/CodeGen/IntrinsicLowering.cpp (original) +++ llvm/trunk/lib/CodeGen/IntrinsicLowering.cpp Mon Sep 22 14:51:58 2008 @@ -34,6 +34,25 @@ M.getOrInsertFunction(Name, FunctionType::get(RetTy, ParamTys, false)); } +static void EnsureFPIntrinsicsExist(Module &M, Module::iterator I, + const char *FName, + const char *DName, const char *LDName) { + // Insert definitions for all the floating point types. + switch((int)I->arg_begin()->getType()->getTypeID()) { + case Type::FloatTyID: + EnsureFunctionExists(M, FName, I->arg_begin(), I->arg_end(), + Type::FloatTy); + case Type::DoubleTyID: + EnsureFunctionExists(M, DName, I->arg_begin(), I->arg_end(), + Type::DoubleTy); + case Type::X86_FP80TyID: + case Type::FP128TyID: + case Type::PPC_FP128TyID: + EnsureFunctionExists(M, LDName, I->arg_begin(), I->arg_end(), + I->arg_begin()->getType()); + } +} + /// ReplaceCallWith - This function is used when we want to lower an intrinsic /// call to a call of an external function. This handles hard cases such as /// when there was already a prototype for the external function, and if that @@ -101,139 +120,31 @@ TD.getIntPtrType(), (Type *)0); break; case Intrinsic::sqrt: - switch((int)I->arg_begin()->getType()->getTypeID()) { - case Type::FloatTyID: - EnsureFunctionExists(M, "sqrtf", I->arg_begin(), I->arg_end(), - Type::FloatTy); - case Type::DoubleTyID: - EnsureFunctionExists(M, "sqrt", I->arg_begin(), I->arg_end(), - Type::DoubleTy); - case Type::X86_FP80TyID: - case Type::FP128TyID: - case Type::PPC_FP128TyID: - EnsureFunctionExists(M, "sqrtl", I->arg_begin(), I->arg_end(), - I->arg_begin()->getType()); - } + EnsureFPIntrinsicsExist(M, I, "sqrtf", "sqrt", "sqrtl"); break; case Intrinsic::sin: - switch((int)I->arg_begin()->getType()->getTypeID()) { - case Type::FloatTyID: - EnsureFunctionExists(M, "sinf", I->arg_begin(), I->arg_end(), - Type::FloatTy); - case Type::DoubleTyID: - EnsureFunctionExists(M, "sin", I->arg_begin(), I->arg_end(), - Type::DoubleTy); - case Type::X86_FP80TyID: - case Type::FP128TyID: - case Type::PPC_FP128TyID: - EnsureFunctionExists(M, "sinl", I->arg_begin(), I->arg_end(), - I->arg_begin()->getType()); - } + EnsureFPIntrinsicsExist(M, I, "sinf", "sin", "sinl"); break; case Intrinsic::cos: - switch((int)I->arg_begin()->getType()->getTypeID()) { - case Type::FloatTyID: - EnsureFunctionExists(M, "cosf", I->arg_begin(), I->arg_end(), - Type::FloatTy); - case Type::DoubleTyID: - EnsureFunctionExists(M, "cos", I->arg_begin(), I->arg_end(), - Type::DoubleTy); - case Type::X86_FP80TyID: - case Type::FP128TyID: - case Type::PPC_FP128TyID: - EnsureFunctionExists(M, "cosl", I->arg_begin(), I->arg_end(), - I->arg_begin()->getType()); - } + EnsureFPIntrinsicsExist(M, I, "cosf", "cos", "cosl"); break; case Intrinsic::pow: - switch((int)I->arg_begin()->getType()->getTypeID()) { - case Type::FloatTyID: - EnsureFunctionExists(M, "powf", I->arg_begin(), I->arg_end(), - Type::FloatTy); - case Type::DoubleTyID: - EnsureFunctionExists(M, "pow", I->arg_begin(), I->arg_end(), - Type::DoubleTy); - case Type::X86_FP80TyID: - case Type::FP128TyID: - case Type::PPC_FP128TyID: - EnsureFunctionExists(M, "powl", I->arg_begin(), I->arg_end(), - I->arg_begin()->getType()); - } + EnsureFPIntrinsicsExist(M, I, "powf", "pow", "powl"); break; case Intrinsic::log: - switch((int)I->arg_begin()->getType()->getTypeID()) { - case Type::FloatTyID: - EnsureFunctionExists(M, "logf", I->arg_begin(), I->arg_end(), - Type::FloatTy); - case Type::DoubleTyID: - EnsureFunctionExists(M, "log", I->arg_begin(), I->arg_end(), - Type::DoubleTy); - case Type::X86_FP80TyID: - case Type::FP128TyID: - case Type::PPC_FP128TyID: - EnsureFunctionExists(M, "logl", I->arg_begin(), I->arg_end(), - I->arg_begin()->getType()); - } + EnsureFPIntrinsicsExist(M, I, "logf", "log", "logl"); break; case Intrinsic::log2: - switch((int)I->arg_begin()->getType()->getTypeID()) { - case Type::FloatTyID: - EnsureFunctionExists(M, "log2f", I->arg_begin(), I->arg_end(), - Type::FloatTy); - case Type::DoubleTyID: - EnsureFunctionExists(M, "log2", I->arg_begin(), I->arg_end(), - Type::DoubleTy); - case Type::X86_FP80TyID: - case Type::FP128TyID: - case Type::PPC_FP128TyID: - EnsureFunctionExists(M, "log2l", I->arg_begin(), I->arg_end(), - I->arg_begin()->getType()); - } + EnsureFPIntrinsicsExist(M, I, "log2f", "log2", "log2l"); break; case Intrinsic::log10: - switch((int)I->arg_begin()->getType()->getTypeID()) { - case Type::FloatTyID: - EnsureFunctionExists(M, "log10f", I->arg_begin(), I->arg_end(), - Type::FloatTy); - case Type::DoubleTyID: - EnsureFunctionExists(M, "log10", I->arg_begin(), I->arg_end(), - Type::DoubleTy); - case Type::X86_FP80TyID: - case Type::FP128TyID: - case Type::PPC_FP128TyID: - EnsureFunctionExists(M, "log10l", I->arg_begin(), I->arg_end(), - I->arg_begin()->getType()); - } + EnsureFPIntrinsicsExist(M, I, "log10f", "log10", "log10l"); break; case Intrinsic::exp: - switch((int)I->arg_begin()->getType()->getTypeID()) { - case Type::FloatTyID: - EnsureFunctionExists(M, "expf", I->arg_begin(), I->arg_end(), - Type::FloatTy); - case Type::DoubleTyID: - EnsureFunctionExists(M, "exp", I->arg_begin(), I->arg_end(), - Type::DoubleTy); - case Type::X86_FP80TyID: - case Type::FP128TyID: - case Type::PPC_FP128TyID: - EnsureFunctionExists(M, "expl", I->arg_begin(), I->arg_end(), - I->arg_begin()->getType()); - } + EnsureFPIntrinsicsExist(M, I, "expf", "exp", "expl"); break; case Intrinsic::exp2: - switch((int)I->arg_begin()->getType()->getTypeID()) { - case Type::FloatTyID: - EnsureFunctionExists(M, "exp2f", I->arg_begin(), I->arg_end(), - Type::FloatTy); - case Type::DoubleTyID: - EnsureFunctionExists(M, "exp2", I->arg_begin(), I->arg_end(), - Type::DoubleTy); - case Type::X86_FP80TyID: - case Type::FP128TyID: - case Type::PPC_FP128TyID: - EnsureFunctionExists(M, "exp2l", I->arg_begin(), I->arg_end(), - I->arg_begin()->getType()); - } + EnsureFPIntrinsicsExist(M, I, "exp2f", "exp2", "exp2l"); break; } } From dalej at apple.com Mon Sep 22 15:06:52 2008 From: dalej at apple.com (Dale Johannesen) Date: Mon, 22 Sep 2008 13:06:52 -0700 Subject: [llvm-commits] [llvm] r55781 - /llvm/trunk/lib/Transforms/Scalar/SimplifyLibCalls.cpp In-Reply-To: <200809222055.43490.baldrick@free.fr> References: <200809041830.m84IUmxP007821@zion.cs.uiuc.edu> <944A649C-5E3A-4E9C-9A71-830C9E64E471@apple.com> <200809222055.43490.baldrick@free.fr> Message-ID: On Sep 22, 2008, at 11:55 AMPDT, Duncan Sands wrote: >> Actually neither readnone nor readonly does a good job of capturing >> the semantics of (say) log; we want something in between that means >> "reads rounding mode but not memory". As discussed elsewhere. > > And as Chris pointed out somewhere, it's rather pointless to > try to get correct rounding mode behaviour for calls to functions > like sin & log, when simpler operations like multiplication and > division currently don't pay any attention to the rounding mode. > So I'm sorry I was so annoying about the rounding mode before :) It's OK. If we accept that the rounding mode handling should be conservatively correct (which I'm not so sure about), we have to start somewhere. Might as well be here. From ggreif at gmail.com Mon Sep 22 15:08:26 2008 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 22 Sep 2008 20:08:26 -0000 Subject: [llvm-commits] [llvm] r56457 - /llvm/branches/ggreif/use-diet/lib/VMCore/Use.cpp Message-ID: <200809222008.m8MK8UmB032199@zion.cs.uiuc.edu> Author: ggreif Date: Mon Sep 22 15:08:20 2008 New Revision: 56457 URL: http://llvm.org/viewvc/llvm-project?rev=56457&view=rev Log: first (untested but performant) implementation of Use::swap Modified: llvm/branches/ggreif/use-diet/lib/VMCore/Use.cpp Modified: llvm/branches/ggreif/use-diet/lib/VMCore/Use.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/branches/ggreif/use-diet/lib/VMCore/Use.cpp?rev=56457&r1=56456&r2=56457&view=diff ============================================================================== --- llvm/branches/ggreif/use-diet/lib/VMCore/Use.cpp (original) +++ llvm/branches/ggreif/use-diet/lib/VMCore/Use.cpp Mon Sep 22 15:08:20 2008 @@ -20,7 +20,30 @@ //===----------------------------------------------------------------------===// void Use::swap(Use &RHS) { - Value *V1(Val1); + ptrdiff_t dist((char*)&RHS - (char*)this); + + if (dist) { + Use *valid1(stripTag(Next)); + Use *valid2(stripTag(RHS.Next)); + if (valid1 && valid2) { + bool real1(fullStopTagN != extractTag(Next)); + bool real2(fullStopTagN != extractTag(RHS.Next)); + (char*&)*stripTag(Prev) += dist; + (char*&)*stripTag(RHS.Prev) -= dist; + if (real1) + (char*&)valid1->Next += dist; + if (real2) + (char*&)valid2->Next -= dist; + + } + + // swap the members + std::swap(Next, RHS.Next); + Use** Prev1 = transferTag(Prev, stripTag(RHS.Prev)); + RHS.Prev = transferTag(RHS.Prev, stripTag(Prev)); + Prev = Prev1; + } + /* Value *V1(Val1); Value *V2(RHS.Val1); if (V1 != V2) { if (V1) { @@ -42,6 +65,7 @@ RHS.Val1 = 0; } } + */ } //===----------------------------------------------------------------------===// From dalej at apple.com Mon Sep 22 15:13:36 2008 From: dalej at apple.com (Dale Johannesen) Date: Mon, 22 Sep 2008 13:13:36 -0700 Subject: [llvm-commits] [llvm] r55673 - in /llvm/trunk: lib/Transforms/IPO/Inliner.cpp test/Transforms/Inline/2008-09-02-AlwaysInline.ll test/Transforms/Inline/2008-09-02-NoInline.ll In-Reply-To: <8A709906-22DF-4CCC-BE36-127F719EE96A@apple.com> References: <200809022216.m82MGDNg021600@zion.cs.uiuc.edu> <200809030859.25530.baldrick@free.fr> <8A709906-22DF-4CCC-BE36-127F719EE96A@apple.com> Message-ID: On Sep 22, 2008, at 11:02 AMPDT, Devang Patel wrote: > > On Sep 21, 2008, at 8:36 PM, Chris Lattner wrote: > >> >> On Sep 3, 2008, at 9:41 AM, Devang Patel wrote: >> >>> >>> On Sep 2, 2008, at 11:59 PM, Duncan Sands wrote: >>> >>>> Hi Devang, >>>> >>>>> respect inline=never and inline=always notes. >>>> >>>> what happens if you set inline=always on a function >>>> that calls itself? Does the inliner go into an >>>> infinite loop? >>> >>> That'd be a bug. >> >> Ok, so what happens now? Is that a bug in the current code, or have >> you fixed that? > > The inliner does not inline a call where caller and callee are same. > inline=always does not override this behavior. Hmm. gcc does have internal support for recursive inlining and several documented parameters of the form --max-inline-recursive-xxx, but I haven't been able to get it to fire....if you want to experiment, remember to turn off tail recursion. I've seen the sentiment expressed that always-inline on a recursive function ought to be reported as an error, but gcc doesn't do that now, seems to quietly ignore always-inline. I don't have a strong opinion myself. > The inliner may decide to not inline due to various reasons : > - caller == callee > - weak linkage > - function takes variable number of args > - GCs do not match > > inline=always does not override these checks. > - > Devang > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From clattner at apple.com Mon Sep 22 15:32:30 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 22 Sep 2008 13:32:30 -0700 Subject: [llvm-commits] [llvm] r56456 - /llvm/trunk/lib/CodeGen/IntrinsicLowering.cpp In-Reply-To: <200809221951.m8MJpwZr031588@zion.cs.uiuc.edu> References: <200809221951.m8MJpwZr031588@zion.cs.uiuc.edu> Message-ID: On Sep 22, 2008, at 12:51 PM, Dale Johannesen wrote: > Author: johannes > Date: Mon Sep 22 14:51:58 2008 > New Revision: 56456 > > URL: http://llvm.org/viewvc/llvm-project?rev=56456&view=rev > Log: > Refactor FP intrinisic setup. Per review feedback. Thanks Dale! -Chris From clattner at apple.com Mon Sep 22 15:33:47 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 22 Sep 2008 13:33:47 -0700 Subject: [llvm-commits] [llvm] r55673 - in /llvm/trunk: lib/Transforms/IPO/Inliner.cpp test/Transforms/Inline/2008-09-02-AlwaysInline.ll test/Transforms/Inline/2008-09-02-NoInline.ll In-Reply-To: <8A709906-22DF-4CCC-BE36-127F719EE96A@apple.com> References: <200809022216.m82MGDNg021600@zion.cs.uiuc.edu> <200809030859.25530.baldrick@free.fr> <8A709906-22DF-4CCC-BE36-127F719EE96A@apple.com> Message-ID: On Sep 22, 2008, at 11:02 AM, Devang Patel wrote: > > On Sep 21, 2008, at 8:36 PM, Chris Lattner wrote: > >> >> On Sep 3, 2008, at 9:41 AM, Devang Patel wrote: >> >>> >>> On Sep 2, 2008, at 11:59 PM, Duncan Sands wrote: >>> >>>> Hi Devang, >>>> >>>>> respect inline=never and inline=always notes. >>>> >>>> what happens if you set inline=always on a function >>>> that calls itself? Does the inliner go into an >>>> infinite loop? >>> >>> That'd be a bug. >> >> Ok, so what happens now? Is that a bug in the current code, or >> have you fixed that? > > The inliner does not inline a call where caller and callee are same. > inline=always does not override this behavior. > > The inliner may decide to not inline due to various reasons : > - caller == callee > - weak linkage > - function takes variable number of args > - GCs do not match > > inline=always does not override these checks. Ok, makes sense! -Chris From clattner at apple.com Mon Sep 22 15:35:26 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 22 Sep 2008 13:35:26 -0700 Subject: [llvm-commits] [llvm-gcc-4.2] r55718 - /llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp In-Reply-To: <7AE2A0A8-5EFC-4559-A100-14B2BB4C89A5@apple.com> References: <200809032001.m83K1RkI012649@zion.cs.uiuc.edu> <4DF68CD0-1A0C-4B54-AE37-0F8D18FDF11D@apple.com> <7AE2A0A8-5EFC-4559-A100-14B2BB4C89A5@apple.com> Message-ID: <1BAD5C02-8779-40FD-88C6-6C75B33ABA6B@apple.com> On Sep 22, 2008, at 11:21 AM, Devang Patel wrote: > > On Sep 21, 2008, at 8:43 PM, Chris Lattner wrote: > >>> + else { >>> + // The inliner pass won't be inserted based on command line >>> options. >>> + // Use AlwaysInliner to handle functions that are marked as >>> always_inline. >>> + bool NeedAlwaysInliner = false; >>> + for (Module::iterator I = TheModule->begin(), E = TheModule- >>> >end(); >>> + I != E; ++I) >>> + if (!I->isDeclaration() && I->getNotes() == >>> FN_NOTE_AlwaysInline) { >>> + NeedAlwaysInliner = true; >>> + break; >>> + } >>> + if (NeedAlwaysInliner) >>> + PM->add(createAlwaysInlinerPass()); >> >> Please don't do this loop here, just unconditionally add it to the >> passmgr. Is there some advantage to checking here (in llvmgcc) >> rather than in the pass itself? > > > Only one advantage is a small convenience to llvm developers. When > we are using -analyze or -print or intentionally running selected > pass for debugging/testing then you do not want PassManager to annoy > you. This is not a big deal, and I do not see any advantage for end > users. How would it be annoying? I don't understand. It is just an optimization to speed up the pass. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20080922/cb34e65d/attachment.html From foldr at codedgers.com Mon Sep 22 15:45:33 2008 From: foldr at codedgers.com (Mikhail Glushenkov) Date: Mon, 22 Sep 2008 20:45:33 -0000 Subject: [llvm-commits] [llvm] r56458 - in /llvm/trunk: tools/llvmc2/doc/LLVMC-Enhancements.rst tools/llvmc2/doc/LLVMC-Reference.rst tools/llvmc2/doc/LLVMC-Tutorial.rst utils/TableGen/LLVMCConfigurationEmitter.cpp Message-ID: <200809222045.m8MKjbmx001074@zion.cs.uiuc.edu> Author: foldr Date: Mon Sep 22 15:45:17 2008 New Revision: 56458 URL: http://llvm.org/viewvc/llvm-project?rev=56458&view=rev Log: Delete the file llvmc2/doc/LLVMC-Enhancements.rst + some minor language/spelling fixes. Removed: llvm/trunk/tools/llvmc2/doc/LLVMC-Enhancements.rst Modified: llvm/trunk/tools/llvmc2/doc/LLVMC-Reference.rst llvm/trunk/tools/llvmc2/doc/LLVMC-Tutorial.rst llvm/trunk/utils/TableGen/LLVMCConfigurationEmitter.cpp Removed: llvm/trunk/tools/llvmc2/doc/LLVMC-Enhancements.rst URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc2/doc/LLVMC-Enhancements.rst?rev=56457&view=auto ============================================================================== --- llvm/trunk/tools/llvmc2/doc/LLVMC-Enhancements.rst (original) +++ llvm/trunk/tools/llvmc2/doc/LLVMC-Enhancements.rst (removed) @@ -1,264 +0,0 @@ -Introduction -============ - -Disclaimer: this document is currently somewhat out-of-date and is -retained for reference; for more recent documentation please refer to -LLVMC-Tutorial.rst. - -A complete rewrite of the LLVMC compiler driver is proposed, aimed at -making it more configurable and useful. - -Motivation -========== - -As it stands, the current version of LLVMC does not meet its stated goals -of configurability and extensibility, and is therefore not used -much. The need for enhancements to LLVMC is also reflected in [1]_. The -proposed rewrite will fix the aforementioned deficiences and provide -an extensible, future-proof solution. - -Design -====== - -A compiler driver's job is essentially to find a way to transform a set -of input files into a set of targets, depending on the user-provided -options. Since several methods of transformation can potentially exist, -it's natural to use a directed graph to represent all of them. In this -graph, nodes are tools -- e.g., ``gcc -S`` is a tool that generates -assembly from C language files -- and edges between the nodes indicate -that the output of one tool can be given as input to another -- i.e., -``gcc -S -o - file.c | as``. We'll call this graph the compilation graph. - -The proposed design revolves around the compilation graph and the -following core abstractions: - -- Target - An (intermediate) compilation target. - -- Action - A shell command template that represents a basic compilation - transformation -- example: ``gcc -S $INPUT_FILE -o $OUTPUT_FILE``. - -- Tool - Encapsulates information about a concrete tool used in the - compilation process, produces Actions. Its operation depends on - command-line options provided by the user. - -- GraphBuilder - Constructs the compilation graph. Its operation - depends on command-line options. - -- GraphTraverser - Traverses the compilation graph and constructs a - sequence of Actions needed to build the target file. Its operation - depends on command-line options. - -A high-level view of the compilation process: - - 1. Configuration libraries (see below) are loaded in and the - compilation graph is constructed from the tool descriptions. - - 2. Information about possible options is gathered from (the nodes of) - the compilation graph. - - 3. Options are parsed based on data gathered in step 2. - - 4. A sequence of Actions needed to build the target is constructed - using the compilation graph and provided options. - - 5. The resulting action sequence is executed. - -Extensibility -============== - -To make this design extensible, TableGen [2]_ will be used for -automatic generation of the Tool classes. Users wanting to customize -LLVMC need to write a configuration library consisting of a set of -TableGen descriptions of compilation tools plus a number of hooks -that influence compilation graph construction and traversal. LLVMC -will have the ability to load user configuration libraries at runtime; -in fact, its own basic functionality will be implemented as a -configuration library. - -TableGen specification example ------------------------------- - -This small example specifies a Tool that converts C source to object -files. Note that it is only a mock-up of intended functionality, not a -final specification:: - - def GCC : Tool< - GCCProperties, // Properties of this tool - GCCOptions // Options description for this tool - >; - - def GCCProperties : ToolProperties<[ - ToolName<"GCC">, - InputLanguageName<"C">, - OutputLanguageName<"Object-Code"> - InputFileExtension<"c">, - OutputFileExtension<"o">, - CommandFormat<"gcc -c $OPTIONS $FILES"> - ]>; - - def GCCOptions : ToolOptions<[ - Option< - "-Wall", // Option name - [None], // Allowed values - [AddOption<"-Wall">]>, // Action - - Option< - "-Wextra", // Option name - [None], // Allowed values - [AddOption<"-Wextra">]>, // Action - - Option< - "-W", // Option name - [None], // Allowed values - [AddOption<"-W">]>, // Action - - Option< - "-D", // Option name - [AnyString], // Allowed values - - [AddOptionWithArgument<"-D",GetOptionArgument<"-D">>] - // Action: - // If the driver was given option "-D", add - // option "-D" with the same argument to the invocation string of - // this tool. - > - - ]>; - -Example of generated code -------------------------- - -The specification above compiles to the following code (again, it's a -mock-up):: - - class GCC : public Tool { - - public: - - GCC() { //... } - - // Properties - - static const char* ToolName = "GCC"; - static const char* InputLanguageName = "C"; - static const char* OutputLanguageName = "Object-Code"; - static const char* InputFileExtension = "c"; - static const char* OutputFileExtension = "o"; - static const char* CommandFormat = "gcc -c $OPTIONS $FILES"; - - // Options - - OptionsDescription SupportedOptions() { - OptionsDescription supportedOptions; - - supportedOptions.Add(Option("-Wall")); - supportedOptions.Add(Option("-Wextra")); - supportedOptions.Add(Option("-W")); - supportedOptions.Add(Option("-D", AllowedArgs::ANY_STRING)); - - return supportedOptions; - } - - Action GenerateAction(Options providedOptions) { - Action generatedAction(CommandFormat); Option curOpt; - - curOpt = providedOptions.Get("-D"); - if (curOpt) { - assert(curOpt.HasArgument()); - generatedAction.AddOption(Option("-D", curOpt.GetArgument())); - } - - curOpt = providedOptions.Get("-Wall"); - if (curOpt) - generatedAction.AddOption(Option("-Wall")); - - curOpt = providedOptions.Get("-Wextra"); - if (curOpt) - generatedAction.AddOption(Option("-Wall")); - - curOpt = providedOptions.Get("-W"); - if (curOpt) - generatedAction.AddOption(Option("-Wall")); } - - return generatedAction; - } - - }; - - // defined somewhere... - - class Action { public: void AddOption(const Option& opt) {...} - int Run(const Filenames& fnms) {...} - - } - -Option handling -=============== - -Because one of the main tasks of the compiler driver is to correctly -handle user-provided options, it is important to define this process -in an exact way. The intent of the proposed scheme is to function as -a drop-in replacement for GCC. - -Option syntax -------------- - -The option syntax is specified by the following formal grammar:: - - ::=