headers
Badoo | 10 Feb 03:01
Favicon
Gravatar

Paulo Coutinho left a message for you...

Paulo Coutinho left a message for you...

Its sender and content will be shown only to you and you can delete it at any time. You can instantly reply to it, using the message exchange system. To find out what's in the message, just follow this link:

Check your message...


Some more patiently waiting folks:

Alysson
San Francisco, CA, United States 		Amb
San Francisco, United States
 
Prab
New Delhi, India 		Italo
Campina Grande, Brazil
 


This email is part of our delivery procedure for the message sent by Paulo Coutinho. If you have received this email by mistake, please ignore it. The message will be deleted soon.

Have fun!
The Badoo Team

You have received this email, because a Badoo member has left a message for you on Badoo. This email is automatically generated and any replies to this message will not be monitored or answered. If you don't want to receive any more messages from Badoo, please click here.

 
_______________________________________________
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
Joe Matarazzo | 10 Feb 02:23
Picon
Gravatar

Prevent DAG combiner from changing "store ConstFP, addr" to integer store

This code lives in DAGCombiner.cpp:


-------------
  // Turn 'store float 1.0, Ptr' -> 'store int 0x12345678, Ptr'
  if (ConstantFPSDNode *CFP = dyn_cast<ConstantFPSDNode>(Value)) {
    // NOTE: If the original store is volatile, this transform must not increase
    // the number of stores.  For example, on x86-32 an f64 can be stored in one
    // processor operation but an i64 (which is not legal) requires two.  So the
    // transform should not be done in this case.
    if (Value.getOpcode() != ISD::TargetConstantFP) {
      SDValue Tmp;
      switch (CFP->getValueType(0).getSimpleVT().SimpleTy) {
      default: llvm_unreachable("Unknown FP type");
      case MVT::f80:    // We don't do this for these yet.
      case MVT::f128:
      case MVT::ppcf128:
        break;
      case MVT::f32:
        if ((isTypeLegal(MVT::i32) && !LegalOperations && !ST->isVolatile()) ||
            TLI.isOperationLegalOrCustom(ISD::STORE, MVT::i32)) {
          Tmp = DAG.getConstant((uint32_t)CFP->getValueAPF().
                              bitcastToAPInt().getZExtValue(), MVT::i32);
          return DAG.getStore(Chain, N->getDebugLoc(), Tmp,
                              Ptr, ST->getPointerInfo(), ST->isVolatile(),
                              ST->isNonTemporal(), ST->getAlignment());
        }
        break;
-------------

What would be the proper way to inhibit this change? In my target (a custom b/e) MVT::i32 is a legal type, and I have a "store MVT::i32" instruction, but I want to later promote the store to a MOV (in a custom lowering step), and this code above is changing the register class, such that it won't coalesce. The debug output looks like this (%Xn are phys regs in F32RC regclass)

--------------
BB#0: derived from LLVM BB %entry
%vreg0<def> = MOV_I32_RI 1; I32RC:%vreg0
%X0<def> = COPY %vreg0; I32RC:%vreg0
%vreg1<def> = MOV_I32_RI 0; I32RC:%vreg1
%X1<def> = COPY %vreg1; I32RC:%vreg1
%X2<def> = COPY %vreg1; I32RC:%vreg1
RET

# End machine code for function foo

********** SIMPLE REGISTER COALESCING **********
********** Function: foo
********** JOINING INTERVALS ***********
entry:
32L %X0<def> = COPY %vreg0<kill>; I32RC:%vreg0
Not coalescable.
--------------

I thought about using the ISD::TargetConstantFP designation on the source, but how does that get set? I couldn't see it used anywhere in the up-front Lower stage of SelectionDAG creation.

Or, if I'm just not approaching the machine code/setup correctly, please let me know that too. :)

Thanks,
Joe
_______________________________________________
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
Duncan Sands | 9 Feb 22:22
Picon
Favicon

Your commit 149912 "Remove some dead code and tidy things up"...

Hi Chris, this was a very tempting commit to make, unfortunately it broke
pattern matching of vectors of booleans.  The problem is that a
ConstantDataVector is only formed if the element type is one of i8, i16, etc.
So vectors of funky types, or not so funky types like i1, are no longer
matched.  I noticed this while working on PR11948.  The good thing is that
the testcase there no longer crashes the compiler because earlier patterns
now fail to match :)  The bad thing is that a -instsimplify testcase like the
following no longer passes:
   define <2 x i1> @vectorselect1(<2 x i1> %cond) {
   ; CHECK: @vectorselect1
     %invert = xor <2 x i1> %cond, <i1 1, i1 1>
     %s = select <2 x i1> %invert, <2 x i32> <i32 0, i32 0>, <2 x i32> <i32 1, 
i32 1>
     %c = icmp ne <2 x i32> %s, <i32 0, i32 0>
     ret <2 x i1> %c
   ; CHECK: ret <2 x i1> %cond
   }

Ciao, Duncan.

> Index: PatternMatch.h
> ===================================================================
> --- PatternMatch.h      (revision 149911)
> +++ PatternMatch.h      (revision 149912)
> @@ -98,13 +98,6 @@
>        Res = &CI->getValue();
>        return true;
>      }
> -    // FIXME: Remove this.
> -    if (ConstantVector *CV = dyn_cast<ConstantVector>(V))
> -      if (ConstantInt *CI =
> -          dyn_cast_or_null<ConstantInt>(CV->getSplatValue())) {
> -        Res = &CI->getValue();
> -        return true;
> -      }
>      if (ConstantDataVector *CV = dyn_cast<ConstantDataVector>(V))
>        if (ConstantInt *CI =
>            dyn_cast_or_null<ConstantInt>(CV->getSplatValue())) {
...
Permalink | Reply | 0 comments |
headers
Jason Kim | 9 Feb 20:43
Gravatar

Questions on MachineFunctionPass and relaxation of pcrel calls (ARM/thumb2)

While implementing a MachineFunctionPass that runs as part of the ARMTargetMachine::addPreEmitPass(), I've run into a problem.
This particular MFP can drastically increase the size (in MachineInstr count) of the MachineFunction that it processes, so much so that
there is a real danger of pcrel calls and branches that use immediate offsets to not be sufficient.

A naive test confirmed that under extreme duress, LLVM does not produce correct BL/B sequences, as it defaults to using pcrel immediates which do not have enough bits to encode the offset.

How do I convince LLVM to revert to materializing an offset in a register and use register indirect BL/B sequences?  Is there some magic sequence of getAnalysisUsage() which will tell the outer loop to replace the immediate form of branches in lieu of a register indirect BL/B ?

Or is the answer to use some other framework (ModulePass?)  Or is this a case where I need to carry out 'manual' (un)relaxation?

In either case, pointers and advice would be greatly appreciated.

Thanks!
-Jason
_______________________________________________
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
tarun agrawal | 9 Feb 20:02
Picon
Favicon

Difficulty inserting putchar in IR

Hi,

I have written a simple code to  insert putchar() function into IR.
It compiled well but when  I tried to run the generated .bc file with lli, its not showing
proper output.

Function *putchar_func = cast<Function>(M->
    getOrInsertFunction("putchar", IntegerType::getInt32Ty(Context),
                        IntegerType::getInt32Ty(Context), NULL));

  Value *One = ConstantInt::get(Type::getInt32Ty(Context), 1);
                                              
  CallInst *CallFibX1 = CallInst::Create(putchar_func, One, "fibx1", BB);
  CallFibX1->setTailCall();



Thanks and Regards,
Tarun Agrawal

_______________________________________________
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
James Molloy | 9 Feb 19:42
Favicon

EU conference 2012 - last call for submissions!

Hi all,

 

The deadline for presentation and tutorial submissions to the EU conference 2012 is the end of tomorrow, Friday 10th February 2012.

 

There are still plenty of available presentation slots, so please don’t be shy in contributing!

 

Cheers,

 

James

_______________________________________________
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
Михаил | 9 Feb 17:50
Picon
Gravatar

Need Help with StructType inheritance

Hi.

I have such task: to get information about classes of work program (module) form Module (LLVM class), for example in ModulePass. I tried to analyze source code of LLVM architecture related with Module class, but I have not founded any useful information. Thanks!

Yours sincerely,
Kadysev Mikhail
 

_______________________________________________
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
Bendersky, Eli | 9 Feb 16:17
Picon
Favicon

generating !llvm.dbg.sp

Hello,

 

According to the documentation here - http://llvm.org/docs/SourceLevelDebugging.html:

 

>>    All subprogram descriptors are collected by a named metadata !llvm.dbg.sp.

 

LLVM seems to have lost the ability to generate this metadata node in r126871, when DIFactory was removed.

 

Is this an intended change? We were relying in the existence of this node, and things broke once we switched from LLVM 2.8 to 3.0.

Is there an alternative location where all the subprogram debug descriptors (DW_TAG_subprogram) can be obtained?

 

Thanks in advance,

Eli

 

 

 

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
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
Colin Benner | 9 Feb 14:22
Gravatar

Problem with the OCaml garbage collector interface and gcroot

Hi all,

As part of my bachelor's thesis I'm trying to implement a new
LLVM-based back end for the OCaml compiler.  Currently I have a
problem with LLVM's interface to the OCaml garbage collector.  When I
try to compile the attached program using llc I get the following
stack dump:

0  llc             0x00000000016611de
1  llc             0x00000000016616aa
2  libpthread.so.0 0x00007f90105fa270
3  llc             0x0000000000adb030 llvm::MachineFrameInfo::getObjectOffset(int) const + 32
4  llc             0x0000000000e73f1a llvm::X86FrameLowering::getFrameIndexOffset(llvm::MachineFunction
const&, int) const + 74
5  llc             0x000000000119bed1
6  llc             0x000000000119bd1e
7  llc             0x00000000011e0dce llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 110
8  llc             0x000000000158e363 llvm::FPPassManager::runOnFunction(llvm::Function&) + 467
9  llc             0x000000000158e6ed llvm::FPPassManager::runOnModule(llvm::Module&) + 125
10 llc             0x000000000158e940 llvm::MPPassManager::runOnModule(llvm::Module&) + 496
11 llc             0x000000000158eefc llvm::PassManagerImpl::run(llvm::Module&) + 172
12 llc             0x000000000158f2f1 llvm::PassManager::run(llvm::Module&) + 33
13 llc             0x0000000000a32322 main + 3010
14 libc.so.6       0x00007f900f85738d __libc_start_main + 237
15 llc             0x0000000000a30c39
Stack dump:
0.      Program arguments: llc testcase.ll
1.      Running pass 'Function Pass Manager' on module 'testcase.ll'.
2.      Running pass 'Analyze Machine Code For Garbage Collection' on function '@foo'

However, the problem goes away when I change the code in a few minor
details.  For instance, changing the 15 in line 36 to pretty much
everything except -16, -8, 1, 2, 3, 4, 8, 16 and 23 makes the problem
disappear, as does switching lines 41 and 42 or changing just about
any other literal in the code.

I'm using LLVM 3.0.  The host and target architecture is x86_64 but
the same problem occures when targetting sparc and sparcv9, but none
of the other architectures.

Any help would be appreciated.

Thanks,
Colin Benner
Attachment (testcase.ll): application/octet-stream, 982 bytes
_______________________________________________
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
Meador Inge | 9 Feb 03:49
Picon
Gravatar

x86-64 sign extension for parameters and return values

I recently noticed a difference between the way GCC and LLVM treat
sign extension for parameters and return values on x86-64.  I could
not find a clear answer in the x86-64 ABI [1] concerning whether
parameters should be sign extended by the caller or callee and
similarly whether return values should be sign extended by the caller
or callee.

Consider a simple 'signed char' division routine:

signed char sdiv(signed char x, signed char y)
{
  return x / y;
}

On my Fedora 16 Linux host GCC 4.6.2 produces:

sdiv:
.LFB11:
        .cfi_startproc
        movsbl  %dil, %eax
        movsbl  %sil, %esi
        movl    %eax, %edx
        sarl    $31, %edx
        idivl   %esi
        ret

where as clang 2.9 produces:

sdiv:                                   # @sdiv
.Leh_func_begin0:
# BB#0:
        movl    %edi, %eax
        cltd
        idivl   %esi
        movsbl  %al, %eax
        ret

GCC assumes the parameters have *not* been sign extended and assumes
it is the receivers job to extend the return value.  LLVM assumes the
parameters *have* been sign extended and that the receiver expects a
sign extended result.

The LLVM model implies the the caller always has to sign extend for
signed promotion to argument registers and that the callee always has
to sign extend for signed promotion to return value registers.  The
GCC model seems more reasonable and efficient to me because whoever is
actually using the values gets to choose whether a sign extension is
done (or not done at all).

Could someone explain the LLVM implementation to me?

[1] http://www.x86-64.org/documentation/abi.pdf

--

-- 
# Meador
Permalink | Reply | 0 comments |
headers
Marcello Maggioni | 8 Feb 20:08
Picon
Gravatar

Polly and non affine branches in ScoPs

Hi, I'm using Polly to analyze memory access patterns for an
university project and I'm trying to get polly working on some loops
that polly marks as "containing non affine branches" .

>From what I understand polly skips Scops that contain these branches
(which comprises something like "if (i % 2 == 0)" where i is a loop
varying variable) because these kind of branches can make , in
practice , non affine the accesses to the memory operands even if the
array subscript expression is affine itself, but I need a much more
"flow-insensitive" and less precise evaluation of the memory access
patterns , so, I would like polly to continue it's analysis on the
memory accesses of the scops even if these branches are present,
because even if the analysis gets wrong thanks to these branches it is
not that big of a deal for my project.

Can't this feature be implemented like the one that ignores the non
affine memory subscripts in ScoPs? To implement this would be needed a
change in TempScop and ScopInfo or a change only in the code that
verifies the branches in ScopDetection would be enough?

Thanks

Marcello
Permalink | Reply | 0 comments |

Gmane