headers
Jakob Stoklund Olesen | 22 May 2013 23:20
Picon

Avoiding MCRegAliasIterator with register units

LLVM can model some quite complicated register banks now, and we even use registers to model some encoding constraints.

For example, a few ARM instructions like strexd have two register operands that must be an aligned pair of
consecutive GPR registers (like r0, r1). This constraint is modeled with the GPRPair register class
containing R0_R1, R2_R3, ... pseudo-registers.

Sometimes ISAs also assign assembly names to such pseudo-registers, again from ARM:

SPR: (s0, s1, ...) 32-bit floating point registers.
DPR: (d0, d1, ...) Even-odd pairs of consecutive S-registers.
QPR: (q0, q1, ...) Even-odd pairs of consecutive D-registers.

But not all constraints are given 'register' names by the ISA. One vld1 instruction variant can load two
consecutive D-registers, both even-odd and odd-even pairs. An even-odd pair like {d0, d1} is also called
q0, but an odd-even pair like {d1, d2} has no other ISA name.

Since it's a bit random what an ISA decides to call a register and what it decides to call an encoding
constraint, LLVM's concept of a physical register is usually a bit broader, but more consistent. We will
normally define physical registers for all reasonable encoding constraints on register operands. For
example, the LLVM ARM target has physical registers like D1_D2 which don't exist in the ISA.

In a target with many encoding constraints like that, some registers can have a high number of
super-registers, and even more aliases. On the last count, some of the ARM NEON registers had more than 40
aliasing registers.

The register allocator uses register units to deal with the complexity of these register banks. Register
units are more or less the same as leaf registers in the sub-register graph. Register interference is
tracked in terms of register units, and that means it is no longer necessary to scan through the long list of
aliasing registers.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Winter | 22 May 2013 22:25
Favicon

How to write output of a backend to a memory buffer instead of a into a file?

Right now, I am using

TargetMachine::addPassesToEmitFile

to write the output of a backend to a file. How can I tell LLVM to write into a memory buffer instead?


_______________________________________________
LLVM Developers mailing list
LLVMdev <at> cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Permalink | Reply | 1 comment |
headers
Kaylor, Andrew | 22 May 2013 22:04
Picon
Favicon

Re: Static linking of execution engine

Hi Mario,

It turns out that this isn't a problem with the static constructor at all.

EngineBuilder::create() is calling dlopen (by way of sys::DynamicLibrary::loadLibraryPermanently)
with a zero argument to get a handle the current module, which the default memory manager may later use for
external symbol resolution.  Because in your case the program is statically linked, the call to dlopen
fails (errno says the executable couldn't be found in the dynamic linker's module load list).  When this
happens EngineBuilder::create() also fails.

In reality, the EngineBuilder code shouldn't be doing that.  If it is needed at all the memory manager should
be doing it.  If you comment out that call in the EngineBuilder code, your test case will successfully
create the JIT engine.  However, you might have subsequent problems with external symbol resolution.  In
that case, you would need to implement a memory manager that knew how to resolve the missing symbols.

If you prefer not to modify the LLVM code, you can also work around this problem by using
ExecutionEngine::createJIT(), which does not make the dlopen check.  I suspect that code path is not well
tested, so there may be additional problems if you do things that way.

-Andy

-----Original Message-----
From: Mario Schwalbe [mailto:m3o.s6e <at> googlemail.com] 
Sent: Wednesday, May 22, 2013 11:30 AM
To: Kaylor, Andrew
Cc: Mario Schwalbe; LLVM Devel
Subject: Re: [LLVMdev] Static linking of execution engine

Am 22.05.13 19:32, schrieb Kaylor, Andrew:
> If you send me details about how you're building this I'll look into it.

Thanks. I forgot to mention it's LLVM 3.2 on Ubuntu 12.10. The command line is:

$ g++-4.7 ExecutionEngineTest.cpp $(llvm-config --cxxflags --ldflags --libs) -lpthread -ldl $
g++-4.7 -static ExecutionEngineTest.cpp $(llvm-config --cxxflags --ldflags --libs) -lpthread -ldl

The -lpthread -ldl is there explicitly because llvm-config prints them as part of --ldflags before the
dependent LLVM libs.

The first of the above commands works well. The second one does not.

ciao,
Mario
Permalink | Reply | 0 comments |
headers
Greg Fitzgerald | 22 May 2013 21:38
Picon
Gravatar

compiler-rt tests in cmake?

Anybody working on porting the compiler-rt tests to cmake?

The online documentation shows a preference for cmake and ctest, but the CMakeLists file has the comment "Currently the tests have not been ported to CMake, so disable this directory."  How should we be running the test suite?


My immediate issue is that "make check-all" fails in the cmake build when compiler-rt is outside the projects directory.  When I point to compiler-rt with LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR, lit still looks for lit.common.cfg within "projects/compiler-rt" instead of the external directory.  I use similar CMake variables for Clang and Polly and have had no trouble.  Any recommendations for how to fix?

Thanks,
Greg


_______________________________________________
LLVM Developers mailing list
LLVMdev <at> cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Permalink | Reply | 0 comments |
headers
Raghavendra K | 22 May 2013 18:06
Favicon

Linking Debug+Asserts Shared Library libclang.so: final link failed: Bad value


Hi,

I downloaded latest 3.2 release of llvm and clang.
used configure to generate the make files
options used:
 ../configure --enable-debug-symbols=yes --enable-keep-symbols=yes --enable-pic=yes 
--enable-keep-symbols=yes --enable-debug-runtime=yes --enable-optimized=no
--enable-targets=x86 --enable-embed-stdcxx=yes --enable-jit=no CXXFLAGS=-fPIC CFLAGS=-fPIC

Now i get this strange error,cannot link, pls help...how to proceed.

llvm[4]: Linking Debug+Asserts Shared Library libclang.so
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
/home1/ragha/llvmsrc/llvm-3.2.src/build/tools/clang/tools/libclang/Debug+Asserts/ARCMigrate.o:
relocation R_X86_64_PC32 against `std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::data() const <at>  <at> GLIBCXX_3.4' can not be used when making a shared object;
recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: final link
failed: Bad value
collect2: ld returned 1 exit status

regards
ragha
Permalink | Reply | 1 comment |
headers
David Chisnall | 22 May 2013 15:19
Picon
Picon
Favicon

Re: TLS with MCJIT (an experimental patch)

On 22 May 2013, at 13:23, Rafael Espíndola <rafael.espindola <at> gmail.com> wrote:

> Why the private message? If unintentional, please forward this to the list.

Ooops, forgot to hit reply-all.  Didn't the LLVM lists used to default to reply-to-list behaviour?

> So, the JIT is analogous to dlopen, so it should be using general
> dynamic and local dynamic models. It is only the initial exec and
> local exec that require the dynamic linker to allocate memory at
> startup.

The dynamic linker will have allocated the memory because the TLS variable in question is provided by libc. 
It is already allocated before the JIT'd code runs.  The JIT'd code just needs to refer to it.  

> If MCJIT is producing TLS code using initial exec or local exec that is a bug.
> 
> On 22 May 2013 08:14, David Chisnall <David.Chisnall <at> cl.cam.ac.uk> wrote:
>> On 22 May 2013, at 13:01, Rafael Espíndola <rafael.espindola <at> gmail.com> wrote:
>> 
>>> On 22 May 2013 06:22, David Chisnall <David.Chisnall <at> cl.cam.ac.uk> wrote:
>>>> On 15 May 2013, at 01:17, "Kaylor, Andrew" <andrew.kaylor <at> intel.com> wrote:
>>>> 
>>>>> I believe that assertion indicates that something didn't get loaded into the lower 2GB of address
space.  That is, the memory manager isn't allocating memory in that range.
>>>>> 
>>>>> I'm sure there must be a way to allocate memory in that range on FreeBSD.  The system loader has to do it,
right?  I just don't know what makes it happen.
>>>> 
>>>> I've asked around, and we don't seem to have anything that can do it.  Checking the code for rtld, it
explicitly asks for memory at a specific address and keeps track of the regions it has used.
>>> 
>>> 
>>> I was under the impression that, in the small memory model, each .so
>>> had to be small, but because of the use of GOTs and PLTs they could be
>>> anywhere in memory. If we allocate the tls memory in the same
>>> allocator call that allocates space for the text section this would
>>> work, no?
>> 
>> I'm not sure what you mean by 'we' in this context.  The memory for TLS (in this instance) is allocated when
libc is loaded, as one of the first things after rtld starts.  The memory will be accessed via a segment
register, so the offset is actually the thing that must be resolved.  Because this is static at run time
(irrespective of the TLS model, the offset doesn't change during a single program run), the MC loader
could hard-code the offset, irrespective of where it ends up.  The memory for the text section in JIT'd code
is allocated by the memory manager.  We do not have a way of asking rtld to allocate memory for us.
>> 
>> If we're going to go via GOTs and PLTs for calls out of JIT'd code then it seems that we're losing a lot of the
benefit of the JIT, as it knows when doing code generation exactly where every function and every variable is.
>> 
>> David
>>
Permalink | Reply | 6 comments |
headers
Vikram Singh | 22 May 2013 05:58
Picon

Custom delay slot insertion

hi 

I am porting llvm 3.1 for a custom processor. I'm taking reference from
sparc architecture. The problem I'm facing that sparc has 1 delay slot in
call and conditional instructions. In my case some have 1 and some have 2
delay slots. But the backend is inserting only 1 delay slot instruction. I
do not know how to insert more than 1 instruction in the delay slots. 
Please suggest some solution. 

vikram

--
View this message in context: http://llvm.1065342.n5.nabble.com/Custom-delay-slot-insertion-tp57898.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.
Permalink | Reply | 0 comments |
headers
Rick Mann | 22 May 2013 05:51

Header Maps?

I'm battling with Xcode and Boost, so I apologize with the somewhat Xcode-specific parts of my question.

I know Xcode generates Header Maps, and I've looked at clong::HeaderMap. But I don't really know how Xcode
chooses to create Header Maps.

I'm trying to avoid adding a search path for all of Boost, and only including the Boost headers that actually
get used. Xcode seems to inconsistently find headers. One problem is that boost inconsistently uses
quotes-vs.-angle brackets when including.

Anyway, is there a tool that can dump out a .hmap file in human-readable form, to help me see what Xcode is doing?

BTW, I've tried asking on the Xcode list for insight into how Xcode tries to use .hmaps, but have yet to
receive a good answer.

Thanks!

--

-- 
Rick
Permalink | Reply | 0 comments |
headers
Frank Winter | 22 May 2013 02:27
Favicon

Best strategy to add a parameter to a function

I am trying to build a function (C++ Builder) and at the same time 
extend its parameter set. Here's what I try to do:

Value* arg0 = add_param_float("arg0");
Value* tmp = builder->CreateFAdd(arg0,some_previous_value);
Value* arg1 = add_param_float("arg1");

The function add_param_float should add a 'float' parameter to the 
function and return its value. Right now it's implemented like this

Value* add_param_float() {
     return new llvm::Argument( 
llvm::Type::getFloatTy(llvm::getGlobalContext()) , param_next() , 
mainFunc );
}

where param_next just figures some new, unused name for the argument and 
mainFunc is the function being built.

This works to a certain extent. I am seeing issues with certain type 
printers and I assume the way the argument is added to the function is 
not a strictly valid thing to do.
I guess one cannot change the function type once it's created. (Then 
maybe the constructor of Argument should not be public).

However, in my setup I need to add new arguments to the function. What 
would be the best way to do it?

I was thinking of implementing a new function like CloneFunction which 
takes an additional argument that can be added to it. But, is this 
really necessary? Isn't there a simpler, more straight-forward way to do 
this?

Any help/thoughts is appreciated!
Frank
Permalink | Reply | 0 comments |
headers
reed kotler | 21 May 2013 23:38

make check for clang/llvm

I have a test that will only fail if I run clang and not if I run llc by 
itself but it's an llc issue.

Where would I put such a test?

Are there similar tests in the "make check" or "make check-all" suite?

Tia.

Reed
Permalink | Reply | 2 comments |
headers
Frank Winter | 21 May 2013 21:19
Favicon

Is it valid to add parameters to a function once it is created

I create a function with an empty signature:

   void llvm_start_new_function() {
     llvm::outs() << "Staring new LLVM function ...\n";

     Mod = new llvm::Module("module", llvm::getGlobalContext());
     builder = new llvm::IRBuilder<>(llvm::getGlobalContext());

     llvm::FunctionType *funcType = 
llvm::FunctionType::get(builder->getVoidTy(), false);
     mainFunc = llvm::Function::Create(funcType, 
llvm::Function::ExternalLinkage, "main", Mod);

     llvm::BasicBlock* entry = 
llvm::BasicBlock::Create(llvm::getGlobalContext(), "entrypoint", mainFunc);
     builder->SetInsertPoint(entry);

     llvm_counters::param_counter = 0;
     llvm_counters::label_counter = 0;
   }

and then add parameters as needed with something like

     llvm::Argument * u8 = new llvm::Argument( 
llvm::Type::getInt8Ty(llvm::getGlobalContext()) , param_next() , mainFunc );

Is this valid?
Permalink | Reply | 1 comment |

Gmane