gmane.comp.compilers.llvm.devel

Re: RFC: R600, a new backend for AMD GPUs

Justin Holewinski — 2012-05-25T21:37:26

Hi Tom,

I have a higher-level question regarding this back-end.  If I have an LLVM
IR module and run it through this back-end, it seems like the only output
option is a binary format.  Is this a device binary, or another
intermediate format?

If the input LLVM IR module was a compute kernel, how would I go about
executing it on an AMD GPU?  Can I use the APP SDK to load the binary,
perhaps through the CAL interfaces?  How about the OpenCL binary interface?

On Tue, Apr 24, 2012 at 2:52 PM, Tom Stellard <tstellar< at >gmail.com> wrote:

Re: MachineOperand TargetFlags being ignored in register coalescing pass

Jakob Stoklund Olesen — 2012-05-25T19:10:34

On May 25, 2012, at 8:15 AM, Tom Stellard <thomas.stellard< at >amd.com> wrote:


Just use immediate operands.

/jakob

generating LLVM code that meets the C ABI

Zach Devito — 2012-05-25T18:29:58

I want to generate LLVM functions that meet the C ABI for function
calls/returns (preferably on multiple platforms but x86_64 would be OK
for now).
I know that LLVM doesn't handle this completely automatically (e.g.
the type {i32,i32} should be passed as a single i64 on x86_64 linux).
Is there any library that automates the generation of function
declarations meeting the ABI and emit marshalling/demarshalling code
from LLVM's types?
I would imagine that Clang needs to do this internally,  where does
this code live?

Thanks for your help!

Zach

Re: alloc_size metadata

John Criswell — 2012-05-25T17:55:07

Just a nitpick here: in some cases, you can detect if a function is a 
wrapper around an allocator.  A simple data-flow analysis can detect 
whether the function's return value is always the result of a known 
allocator and whether the parameters to the known allocator are a 
function of the function's arguments.

This can work for some allocators, but not all, and I don't know how 
well it works in practice.  However, it's not technically impossible all 
the time.
:)

I think the poolalloc project has an implementation of this analysis: 
poolalloc/lib/DSA/AllocatorIdentification.cpp.

Re: Minor correction to the Visual Studio documentation

Mikael Lyngvig — 2012-05-25T17:46:33

Yes, thank you!  I didn't think of that.


2012/5/25 Anton Korobeynikov <anton< at >korobeynikov.info>

Re: alloc_size metadata

Nuno Lopes — 2012-05-25T17:41:19

It's not a general solution, and not it even for C, of course.
But it's very useful for applications that have their own malloc  
wrappers and implementations. For example, LLVM, which has its own  
allocators! Without this metadata, you'll never be able to analyze  
LLVM's code at all. It's simply impossible to detect, in general, if a  
function is a custom allocator.
So, yes, some metadata is necessary. I agree my proposal is not  
general enough for all applications. For example, I run the tool over  
some code yesterday and I found an allocator that is the following:  
alloc(x, y, x) and allocates 'x * y + z' bytes. And that cannot be  
represented either at source-code level (with GCC's attribute) nor at  
IR level following my metadata proposal.
I'm happy to implement something more general if we come up with a  
better design.

Nuno

Re: Minor correction to the Visual Studio documentation

Anton Korobeynikov — 2012-05-25T17:08:23

Hello Mikael,

Or you can use windows.h from mingw :)

Changes to TargetLowering::{LowerCallTo,LowerCall}

Justin Holewinski — 2012-05-25T16:59:27

A change has just been committed that changes the interface for TargetLowering::LowerCallTo and TargetLowering::LowerCall.  Instead of passing a mess of parameters to these functions, a new structure has been created that encapsulates these parameters.  The motivation is that additional fields can be added to this structure (with appropriate changes to SelectionDAGBuilder for populating the new fields) without forcing an ABI change on each and every target.  In-tree targets have been updated accordingly, so no change is required.  However, if you have an out-of-tree target that is following trunk, please be aware that this *will* break your build.  Please see any in-tree target for the new interface and how to access the values that used to be available as individual function parameters.



As a quick example, the ARM implementation for LowerCall is now:



SDValue

ARMTargetLowering::LowerCall(TargetLowering::CallLoweringInfo &CLI,

                             SmallVectorImpl<SDValue> &InVals) const {

  S

Re: Predicate registers/condition codes question

Sebastian Pop — 2012-05-25T16:54:03

I see that PPC has its condition registers CRRC as i32, and that PPC
also has general purpose i32 registers GPRC, so the situation is slightly
different than on Hexagon, where there are no general purpose registers
of the same size as the predicate registers: i8.

So on PPC it is "safe" to promote from i1 to i32 and to "allow confusion"
between the promoted i32 and the existing operations that were using i32:
as we can always select between a CR and a GPR following the op type.

On Hexagon, if type legalization promotes i1 into i8, that would create
this confusion between the i8 ops existing before legalization and the
newly promoted ones.  Then as Ivan was suggesting, we will have to
provide custom expansion to promote the "illegal" ops on i8 on almost
all the operations, except logical ops.

Sebastian
--
Qualcomm Innovation Center, Inc is a member of Code Aurora Forum

Re: alloc_size metadata

John Criswell — 2012-05-25T16:38:39

True.  It also doesn't handle a number of "C" allocators like strdup(), 
etc.  Making it that general, though, may be tricky, and I don't think 
it negates the utility of the simpler form.  I suspect a fair number of 
allocators could be described by the alloc_size feature.

Even in the C/C++ world, I think it'd be useful.  There's the 
GC_malloc() in Boehm's garbage collector, kmalloc() in the Linux kernel, 
malloc wrappers in applications, memalign(), etc.


I see.  That makes sense.

Re: Predicate registers/condition codes question

Sebastian Pop — 2012-05-25T16:35:00

Hi Ivan,

On Thu, May 24, 2012 at 6:43 PM, Ivan Llopard <ivanllopard< at >gmail.com> wrote:

I will try this, although I think it will be painful to maintain an up
to date list
of ops marked for promotion.

I was hoping to find a way to implement the opposite: specify that the
few logical ops are legal on i8, and the default action on the rest of
opcodes would be to promote to i32.

Another way that would be practical is to "remember" that an i8 type
is the result of a first promotion from i1: that would be a legal i8, and
an i8 type that has not been already promoted is illegal and has to
be promoted to i32.  The only way I found to implement this is with a
different type: p8.


Copies between pred and int registers are allowed in Hexagon.

Sebastian
--
Qualcomm Innovation Center, Inc is a member of Code Aurora Forum

Re: Minor correction to the Visual Studio documentation

Mikael Lyngvig — 2012-05-25T16:32:37

Now I recall what the problem was that I had: My code makes use of the
Win32 API and that means pulling in Windows.h, which again pulls in some
headers that make use of the force_inline thingy, which is not supported
under Windows yet.

I guess if I stuck with portable code, I could probably use Clang for
Windows.  Once again, I have to visit the thinking box and figure out what
to do.

But thanks for the description of how to do this.  It is surely going to
save both me and others a lot of time.

2012/5/25 Nathan Jeffords <blunted2night< at >gmail.com>

_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Re: alloc_size metadata

Hal Finkel — 2012-05-25T16:28:04

On Fri, 25 May 2012 17:43:52 +0200
Duncan Sands <baldrick< at >free.fr> wrote:


I think this is a good point, here's a suggestion:

Have the metadata name two functions, both assumed to have the same
signature as the tagged function, one which returns the offset of the
start of the allocated region and one which returns the length of the
allocated region. Alternatively, these functions could take the same
signature and additionally the returned pointer of the tagged
function, and then one function can return the start of the region and
the other the length.

For static analysis, we can attempt to inline these functions and then
use SCEV (dead code elimination will then get rid of the unused
results). For runtime checks, calls (which may also be inlined) can be
easily constructed.


Does the current code even handle calloc? I only see malloc and new.

 -Hal

Re: -fbounds-checking vs {SAFECode,ASan}

John Criswell — 2012-05-25T16:20:28

While I agree that you're probably correct about the bounds checking 
covering a tiny portion of buffer overflows, I don't think we really 
know that for certain.  An experiment to find the percentage of pointer 
arithmetic operations that can be checked in this way would be interesting.


I agree that any future documentation on any added security attack 
mitigation features should be clear on which attacks are prevented and 
which are not.

Having a security solution that prevents some attacks but not others is 
okay.  Defeating all memory safety attacks with acceptable performance 
is still an open research question.  What I think is important is 
knowing which attacks a technique defeats and at what cost; you 
essentially want to know what you're buying and for how much.

My concern with Nuno's approach is that it is not clear which exploits 
it will prevent and which it will not.  Alternatively, if we implemented 
CFI, we know *exactly* which types of attacks are prevented and which 
are not (and, I th

Re: Minor correction to the Visual Studio documentation

Nathan Jeffords — 2012-05-25T15:57:31

I checkout LLVM and clang from SVN, then use CMake to generate project
files for Visual Studio 2010 (I started with 2008). The LLVM project
compiles successfully and gives me all the tools including Clang. For a few
tests, I compile C++ code with Clang which if I need to I link, I use
MinGW's ld passing all the relevant object files and libraries including
correctly ordering the start-up code and such.

My project is C++ language front end using a CMake build script to generate
a Visual Studio 2010 project. Within the CMake build script I specify each
individual library I need to link against in the correct order.

LLVM is written in C++ so it is the de facto interface.  From what I
understand the C bindings are not complete, but they are quite usable.

this is the library section of my CMake build script for the final
executable:

${PLATFORM_LIBS}

#LLVMX86Disassembler
#LLVMX86AsmParser
LLVMX86AsmPrinter
LLVMX86CodeGen
LLVMX86Utils
LLVMX86Desc
LLVMX86Info

LLVMSelectionDAG

LLVMAsmPrinter

#LLVMJIT
#LLVMExe

Re: alloc_size metadata

Duncan Sands — 2012-05-25T15:43:52

Hi John,

On 25/05/12 17:22, John Criswell wrote:

basically it feels like "I only know about C, here's something that pretends to
be general but only handles C".  Consider a language with a string type that
contains the string length as well as the characters.  It has a library function
allocate_string(length).  How much does it allocate?  length+4 bytes. That can't
be represented by alloc_size.  What's more, it may well store the length at the
start, and return a pointer to just after the length: a pointer to the first
character.  alloc_size can't represent "the allocated memory starts 4 bytes
before the return value" either.  In short, it feels like a hack for handling
something that turns up in some particular C code that someone has, rather than
a general solution to the general problem.


no, I'm thinking that SAFECode won't need to look at or worry about the
attribute at all, because the LLVM methods will know about it and serve
up the appropriate info.  Take a look at Analysis/MemoryBuiltins.h.  In
s

Re: alloc_size metadata

John Criswell — 2012-05-25T15:22:29

Hrm.  I haven't formed an opinion on what the attributes should look 
like.  I think supporting the ones established by GCC would be important 
for compatibility, and on the surface, they look reasonable.  Devising 
better ones for Clang is fine with me.  What about them feels klunky?


It probably could.  It doesn't simply because SAFECode was written 
before these features existed within LLVM.
:)


I'm not sure what you mean by "LLVM utility," but I think we're thinking 
along the same lines.  Clang/LLVM implement the alloc_size attributes, 
we change SAFECode to recognize it, and so when people use it, SAFECode 
benefits automagically.

Am I right that we're thinking the same thing, or did I completely 
misunderstand you?

MachineOperand TargetFlags being ignored in registercoalescing pass

Tom Stellard — 2012-05-25T15:15:08

Hi,

On AMD GPUs we have source modifiers and output modifiers, which are bits
you can set on instructions to perform some simple no cost operations
on either the operands or the result of an instruction (floating point
values only).

The source modifiers are FABS and FNEG and are applied to the operands
before an instruction is executed.

The output modifiers are CLAMP (clamp result between 0.0f and 1.0f)
and OMOD (multiply the result by 0.5f, 2.0f, or 4.0f).  These are
applied to the result of an instruction after it is executed.

For the R600 backend, I'm using the MachineOperand TargetFlags to
keep track of the modifiers, but I've noticed when I use them on
operands to COPY instructions they are not propagated when registers
are coalesced.  Is this a bug, or should I not be using TargetFlags for
storing this kind of information?

-Tom

Re: use AVX automatically if present

Pan, Wei — 2012-05-25T12:54:24

llc built from the current trunk generates avx code as you expected. I tested that. Avx in llvm3.1 is not enabled by default.

-----Original Message-----
From: Henning Thielemann [mailto:llvm< at >henning-thielemann.de] 
Sent: Thursday, May 24, 2012 5:57 PM
To: Pan, Wei
Cc: LLVM developer mailing list
Subject: Re: use AVX automatically if present

On Thu, 24 May 2012, Pan, Wei wrote:

I forgot to mention that I am using recent LLVM-3.1 and in principle my llc knows about avx as I have shown in the second example. But avx does not seem to be used by default.

On Thu, 24 May 2012, Henning Thielemann wrote:

Re: alloc_size metadata

Chandler Carruth — 2012-05-25T07:22:24


I think this is key -- there should be some clear numbers and evidence that
this is a really important semantic extension in order to get accurate and
efficient results.

And as Duncan points out, we should be confident that there is no existing
mechanism to get the same optimization improvements.
_______________________________________________
LLVM Developers mailing list
LLVMdev< at >cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Re: alloc_size metadata

Duncan Sands — 2012-05-25T07:17:58

Hi Kostya,


I don't think you need the attribute for this: LLVM already has utilities that
know about malloc and C++'s new.  Can't you just use them?

Ciao, Duncan.