Steve King | 29 Jan 22:00 2015

creating a vreg in eliminateFrameIndex()

Hello LLVM,
The ARM target sometimes adds an instruction with a virtual register
in eliminateFrameIndex():

This looks late for a virtual register to appear.  Where is this vreg made real?

David Callahan | 29 Jan 21:13 2015

LNT install

I  followed the lnt quickstart directions but got this diagnostic when doing the setup:


bash-3.2$   ~/mysandbox/bin/python ~/lnt/ develop

/Users/dcallahan/mysandbox/lib/python2.7/site-packages/setuptools/ UserWarning: The version spec\

ified requires normalization, consider using '0.4.1.dev0' instead of '0.4.1dev'.



Subsequently I get this error: >


/Users/dcallahan/mysandbox/bin/lnt runtest nt --sandbox /Users/dcallahan/tmp/sand --cc /Users/dcallahan/bu\

ild/Debug+Asserts/bin/clang --test-suite /Users/dcallahan/llvm-test-suite

error: installed distribution LNT 0.4.1.dev0 is not current (LNT 0.4.1dev), you may need to reinstall

LNT or rerun ' develop' if using development mode.



Any pointers on what might be going wrong?




LLVM Developers mailing list
LLVMdev <at>
Sanjoy Das | 29 Jan 20:29 2015

Re: RFC: Proposal for Poison Semantics

> I've been discussing a model with David that might steer poison back towards
> something that simply supports algebraic simplification. If we have a math
> operation that cannot wrap, then it notionally produces as many bits of
> undef as the operation could possibly produce. For example, "add nsw i8" can
> produce an i9 undef, and "mul nsw i8" can produce an undefined 16 bit
> bitpattern. This is strong enough to do things like "a + 1 > a  -->  true",
> because on overflow of "a + 1" we can choose an poison value of "MAX_INT +
> 1", even though that is not a valid i8 bit pattern.
> So, a short version would be that poison is like undef, except you get to
> include the overflow bits of the computation in your undef value.

I  suspect it will be hard to justify reg2mem is meaning preserving in
this scheme.  But if this can be made to work, then I agree that this
is the right thing to do -- an i32 poison effectively has the
semantics of a wider type, and it makes sense to be explicit in that.

-- Sanjoy
Xin Tong | 29 Jan 20:27 2015

always-inline heuristic

I see that we do not inline a function marked as "always-inline" if it contains indirect branches ? what are the reasons behind this criterion ?

LLVM Developers mailing list
LLVMdev <at>
Zachary Turner | 29 Jan 19:20 2015

Adding PDB support to lib\DebugInfo

I've been working on adding pdb reading support to llvm.  This started as a tool for dumping info from a pdb (similar to llvm-dwarfdump), which has been checked in and currently has limited support for dumping pdb.

There's still more to be done on the pdb dumping tool, but at this point -- to reduce duplicated effort -- I think it makes the most sense to start moving some of this logic into a library in llvm, and then change llvm-pdbdump to use the library.  Later, once the library is more comprehensive, I plan to then use it in LLDB for reading PDBs while debugging on Windows.

I think the best way to do this is to move all of the code in lib/DebugInfo to lib/DebugInfo/dwarf, and then make another folder called lib/DebugInfo/pdb.   These would then be compiled into two separate libraries.

Another approach is to just put the PDB code in the same folder as the dwarf code, but I don't like this approach for a number of reasons:

1) Not every consumer of DebugInfo wants both types of DebugInfo.
2) The pdb reading code relies very heavily on Windows APIs, and will not compile on other platforms.  This is solvable with some CMake machinery, but it's ugly and unwarranted in my opinion.

So as a first step in this direction I'd like to propose moving the code in lib/DebugInfo to lib/DebugInfo/dwarf, and then updating the rest of llvm accordingly.

Thoughts?  Comments?  Suggestions?
LLVM Developers mailing list
LLVMdev <at>
Greg Fitzgerald | 29 Jan 19:01 2015

Should llvm include a linker?

I've been thinking about how easy it would be to integrate lld into
the main llvm repo:

1) Preserve history with: `svnadmin load --parent-dir tools/lld . < lld.dump`
2) Move lld's target-specific libraries up to `lib/Target`, and
remaining libraries up to `lib`.
3) Move everything from the lld namespace to the llvm namespace.

But would it be valuable?  I'd think that non-C, llvm-based compilers
like GHC or Rust would have the most to gain.  Anybody else see value
in it?  Maybe those that maintain the Target directories?

In your response, let's please avoid discussion about coding
conventions and sanitizer builds.  Assume that's all resolved before
this integration is considered.

Qiuping Yi | 29 Jan 13:51 2015

How to get Alias Set Information?

Hi, all

I know LLVM has including several implementation of alias anlaysis. Now I
want to get the conservative alias set information, or maybe alias set information.
I print the alias result through command " opt -print-alias-sets -biasicaa .... ",
and I found the basic alias analysis does't consider the global values, so 
if I want to get the maybe alias set information of all variables including global variabels,
which alias analysis pass is better for me? 

In addition, should I get the alias set information through AliasSetTracker?
Now, I am trying to use AliasSetTracker with Basic Alias Analysis as follow: 

PassManager pm;
pm.add(...); // add other passes
aliasInfo = createBasicAliasAnalysisPass();
aliasTracker = new AliasSetTracker(aliasInfo->getAnalysis<AliasAnalysis>());

// For testing this implementation, I using the next code to print the alias set by 
// simulating the code in AliasSetPrinter.

for (Module::iterator MIt = module->begin(); MIt != module->end(); ++MIt) {
    for (Function::iterator FIt = MIt->begin(); FIt != MIt->end(); ++FIt) {
        for (BasicBlock::iterator BIt = FIt->begin(); BIt != FIt->end(); ++BIt) {
            aliasTracker->add(&*BIt);  //***

However, the program crushed at line "***" with the next backtrace information.
So how should I correctly get the alias set information?

0  klee            0x0000000000edc9af
1  klee            0x0000000000edceb9
2 0x00007f2da192bcb0
3  klee            0x0000000000ce327f llvm::AliasSet::aliasesPointer(llvm::Value const*, unsigned long, llvm::MDNode const*, llvm::AliasAnalysis&) const + 95
4  klee            0x0000000000ce73d7 llvm::AliasSetTracker::findAliasSetForPointer(llvm::Value const*, unsigned long, llvm::MDNode const*) + 167
5  klee            0x0000000000ce865a llvm::AliasSetTracker::getAliasSetForPointer(llvm::Value*, unsigned long, llvm::MDNode const*, bool*) + 3562
6  klee            0x0000000000ce8b58 llvm::AliasSetTracker::add(llvm::LoadInst*) + 200
7  klee            0x00000000006480fd klee::Executor::printAliasSet() + 125
8  klee            0x000000000067744e klee::Executor::run(klee::ExecutionState&) + 878
9  klee            0x00000000006793ce klee::Executor::runFunctionAsMain(llvm::Function*, int, char**, char**, std::vector<int, std::allocator<int> >) + 2446
10 klee            0x0000000000635356 main + 10774
11       0x00007f2da0b6776d __libc_start_main + 237
12 klee            0x00000000006408f1
Command terminated by signal 11

Thank you all in advance!

Qiuping Yi
Institute Of Software
Chinese Academy of Sciences
LLVM Developers mailing list
LLVMdev <at>
Galina Kistanova | 29 Jan 02:26 2015

LLVM buildmaster will be restarted soon

Hello everyone,

LLVM buildmaster will be restarted after 6 PM Pacific time today.


LLVM Developers mailing list
LLVMdev <at>
Daniel Berlin | 29 Jan 00:15 2015

[PATCH]: Allow PRE to insert no-cost phi nodes

Current PRE tries to not increase code size.
It does this with a check whether or not the number of places it would have to insert is 1 or not.

The problem with this is that the answer could also be "we have to insert in zero places" in the case it's available in all predecessors.

Normal dominator based elimination in GVN will not catch these cases because the branches do not dominate the merge point.

A simple example
int c;
int d;
int pre(int foo, int a, int b)
      int g;
      if (foo) {
  c = a+b;
      } else {
  d = a+ b;
g = a+b;
return g;

Without this patch, PRE (and GVN) will not eliminate g = a+b.
With this patch, PRE will create phi(c, d) and eliminate g = a + b.

(It is tremendously more difficult to make current GVN understand the problem, and GCC solves this the same way i'm about to).

The patch looks large because of code movement, but it basically all boils down to changing this check:

if (NumWithout != 1 || NumWith == 0)

if (NumWithout > 1 || NumWith == 0)

and skipping insertion when NumWithout == 0

testcase included.

Attachment (pre-no-cost-phi.diff): application/octet-stream, 8 KiB
LLVM Developers mailing list
LLVMdev <at>
Chandler Carruth | 28 Jan 21:56 2015

Would like to force one minor, mechanical change on out-of-tree users of the old pass manager

Greetings folks.

I had really wanted out-of-tree folks to be able to make only a single change to their code due to the new pass manager; essentially, by the time they had to touch the code at all I wanted them to be able to port completely to the new pass manager.

However, Richard has raised the issue that this is nearly impossible to make work with C++ modules, and we've lost the modules build bot that was checking our self host in this mode because of this.

So, now that 3.6 is branched, I wondered if folks would be OK with me switching code to explicitly refer to some of the legacy constructs with the "legacy" namespace. I'm absolutely committed to the new pass manager being done prior to 3.7 (actually, a lot sooner). So this would require (entirely mechanical) source changes to out-of-tree users who are tracking trunk in the interim.

However, the changes would only be required for Pass*Manager* and related classes. Neither Pass, FunctionPass, or PassManagerBuilder would change.

Any objections to this? While it clearly has cost and would not be my preferred approach, the benefits seem to outweigh the costs here.

LLVM Developers mailing list
LLVMdev <at>
Matt Arsenault | 28 Jan 20:52 2015

RFC: Add ISD nodes for mad


I would like to add an ISD node for an fmad operation (named either FMAD 
or FMULADD). It will have the semantics of returning the same result as 
the separate multiply and add with the intermediate rounding step, and 
not a differently rounded result.  The motivation is to share code with 
the various FMA forming DAG combines, but will be generally more useful 
on targets that support it since it is OK to form without non-default 
-fp-contract modes.

This would also be associated with a minor change to the description of 
the llvm.fmuladd intrinsic. The fmuladd intrinsic currently has what I 
think are poorly worded semantics for how it should behave:

" equivalent to the expression a * b + c, except that rounding will 
not be performed between the multiplication and addition steps if the 
code generator fuses the operations. Fusion is not guaranteed, even if 
the target platform supports it."

This is odd because it doesn't guarantee fusion, but if fusion does 
happen, the intermediate rounding is eliminated. This is an odd 
constraint to put on the backend that in my reading doesn't allow ever 
forming a mad with the same intermediate rounding. This is not helpful 
since the fmuladd intrinsic expands to the fmul and fadd in 
SelectionDAGBuilder unless fp-contraction is globally enabled. According 
to this constraint, you could never form a mad because if it was 
expanded from the fmuladd intrinsic, fusion is not allowed. I don't 
think this arbitrary constraint on the backend makes sense, so the 
semantics of fmuladd would be changed to mean that the intermediate 
rounding may or may not happen, but not constrain the backend on only 
fusing if the intermediate rounding is eliminated.