Displaying 20 results from an estimated 100 matches similar to: "[LLVMdev] Fwd: Multiply i8 operands promotes to i32"
2015 Jul 23
0
[LLVMdev] signext on function parameters and return.
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Steve King
> Sent: 23 July 2015 01:45
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] signext on function parameters and return.
>
> Hello,
> For a simple function taking a short and returning a short, clang
> generates IR with this function
2015 Jul 23
1
[LLVMdev] signext on function parameters and return.
On Thu, Jul 23, 2015 at 3:59 AM, Daniel Sanders
<Daniel.Sanders at imgtec.com> wrote:
>
> The target hook is classifyArgumentType() and classifyReturnType() in tools/clang/lib/CodeGen/TargetInfo.cpp and returning ABIArgInfo::getExtend() causes the signext/zeroexts to be emitted appropriately for the type.
Thanks for the great help. Should these classify calls be moved down
into the
2015 Jul 23
2
[LLVMdev] signext on function parameters and return.
Hello,
For a simple function taking a short and returning a short, clang
generates IR with this function signature:
define signext i16 @foo(i16 signext %x)
Some questions please:
1) For the input parameter and return value, does the target control
whether clang uses signext vs something else? If so, how does this
target query work?
2) Does the presence of the signext mean it's imperative
2012 Jun 13
2
[LLVMdev] Structs passed by value
Hello,
I'm trying to change the default behavior for how structures are passed to functions to use pass-by-value. Currently LLVM's default behavior is to pass structures by reference. I'm not disputing the benefits of this but I really want to change the default behavior for experimentation purposes.
To this end I've changed the code in DefaultABIInfo::classifyArgumentType() to
2012 Jun 14
0
[LLVMdev] Structs passed by value
Hi,
On Wed, Jun 13, 2012 at 9:55 AM, Martinez, Javier E <
javier.e.martinez at intel.com> wrote:
> Hello,****
>
> ** **
>
> I’m trying to change the default behavior for how structures are passed to
> functions to use pass-by-value. Currently LLVM’s default behavior is to
> pass structures by reference. I’m not disputing the benefits of this but I
> really want to
2012 Dec 06
2
[LLVMdev] Value of structure passed byval to a recurse function not initialized when accessed through GDB
Hi David,
I think it might not be exactly PR13303 which might be causing the
corruption of struct when accessed through GDB.
This seems to be an ABI problem in clang.
The problem seems to be that when we have pass by value of struct
(having indirect arguments) stack is not aligned properly.
I tried realigning the stack for indirect arguments in(TargetInfo.cpp) -
ABIArgInfo
2012 Dec 06
0
[LLVMdev] Value of structure passed byval to a recurse function not initialized when accessed through GDB
On Thu, Dec 6, 2012 at 12:33 AM, Karthik Bhat <karthikthecool at gmail.com> wrote:
> Hi David,
>
> I think it might not be exactly PR13303 which might be causing the
> corruption of struct when accessed through GDB.
> This seems to be an ABI problem in clang.
> The problem seems to be that when we have pass by value of struct
> (having indirect arguments) stack is not
2014 Nov 24
4
[LLVMdev] Proposed patches for Clang 3.5.1
Hi,
I'd like to propose the following patches for inclusion in Clang 3.5.1.
Proposed clang patches:
* r213769 - Fix test/Driver/cl-x86-flags.c by providing explicit -target
* r214025 - [Driver][Mips] Check output of -dynamic-linker arguments by the Clang driver
* r214662 - [Mips] Add the `mips64-linux-gnu` target to the test case to check `in128` type handling.
*
2011 Feb 22
0
[LLVMdev] Passing structures as pointers, MSVC x64 style
Carl,
See clang/lib/CodeGen/TargetInfo.cpp.
// FIXME: mingw64-gcc emits 128-bit struct as i128
if (Size <= 128 &&
(Size & (Size - 1)) == 0)
return ABIArgInfo::getDirect(llvm::IntegerType::get(getVMContext(),
Size));
It was my workaround, sorry.
Please check to tweak the clause (128 to 64) and lemme
2012 Dec 04
0
[LLVMdev] Value of structure passed byval to a recurse function not initialized when accessed through GDB
This seems to be another case of PR13303 - since GDB can't figure out
where to break for this function based on the debug info (you'll
notice when you "break recurse" that it's not breaking on a line or
source file, just an address) it's breaking at the very start, before
the prologue
I'm about to commit a fix to this.
On Tue, Dec 4, 2012 at 5:34 AM, Karthik Bhat
2014 May 16
2
[LLVMdev] It is possible to somehow turn off coercion of struct parameters into ints?
In particular, I would for example like to prevent that two fields of
type i32 are packed into an i64 parameter. And so on...
Thanks!
-- Zvonimir
2014 Nov 24
4
[LLVMdev] Proposed patches for Clang 3.5.1
> -----Original Message-----
> From: Tom Stellard [mailto:tom at stellard.net]
> Sent: 24 November 2014 17:15
> To: Daniel Sanders
> Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
> Subject: Re: Proposed patches for Clang 3.5.1
>
> On Mon, Nov 24, 2014 at 04:33:28PM +0000, Daniel Sanders wrote:
> > Hi,
> >
> > I'd like to propose the
2011 Feb 21
2
[LLVMdev] Passing structures as pointers, MSVC x64 style
The MS x64 ABI calling convention (http://msdn.microsoft.com/en-us/library/ms235286(VS.80).aspx) says:
Any argument that doesn’t fit in 8 bytes, or is not 1, 2, 4, or 8 bytes, must be passed by reference.
Clang isn't doing that for us when passing our triple, x86_64-pc-win32-macho.
Here's a simple example program:
struct Guid {
unsigned int Data1;
unsigned
2012 Dec 04
4
[LLVMdev] Value of structure passed byval to a recurse function not initialized when accessed through GDB
Hi All,
I was debugging a clang binary when i found this problem. The
following code is complied with clang.
typedef struct s
{
short s;
} SVAL;
void recurse (SVAL a, int depth)
{
a.s = --depth;
if (depth == 0)
return;
else
recurse(a,depth);
}
int main ()
{
SVAL s; s.s = 5;
recurse (s, 5);
return 0;
}
When i try to access value of a.s in function recurse through gdb(i.e
2016 Feb 16
0
Intrinsic opt failure
On 2/16/2016 8:44 AM, Konstantin Vladimirov via llvm-dev wrote:
>
> CI->getArgOperand(0) returns operand with type (double*) rather then
> double, because in our ABI doubles are passed via memory.
The LLVM intrinsics in the LLVM IR must conform to whatever the IR's
requirements are. That means that even in the case of your backend, the
arguments to the intrinsic must be doubles,
2016 Feb 16
2
Intrinsic opt failure
Hi,
Working on private backend, based on llvm-3.7
Inside lib/Transforms/InstCombine/InstCombineCompares.cpp there is
attempt to optimize fabs:
if (F->getIntrinsicID() == Intrinsic::fabs ||
...
switch (I.getPredicate()) {
...
case FCmpInst::FCMP_OGT:
return new FCmpInst(FCmpInst::FCMP_ONE, CI->getArgOperand(0), RHSC);
But
CI->getArgOperand(0)
2020 Aug 30
5
BUG: complete misunterstanding of the MS-ABI
Objects compiled for the MS-ABI don't conform to it!
Data types beyond 64 bit MUST BE returned by the callee via the
hidden first argument allocated by the caller, NOT in XMM0!
Demo/proof: from this source
--- llvm-bug.c ---
#ifndef __clang__
typedef struct {
unsigned __int64 low;
unsigned __int64 high;
} __uint128_t;
#else
__attribute__((ms_abi))
#endif
__uint128_t
2012 Oct 23
1
[LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values
Chandler Carruth <chandlerc at google.com> wrote on 22.10.2012 20:53:54:
> So, I'm not really sure if this is the right approach. I'd like some
> folks from the LLVM side of things to chime in.
>
> In general, I'm not certain we want to continue growing our dependence
> on the signext and zeroext attributes on return types, or whether we
> want to do the
2011 Feb 11
0
[LLVMdev] Compiler error when self-hosting
I've hit this weird compiler error when building llvm/clang
$ clang --version
clang version 2.9 (trunk 125254)
Target: x86_64-apple-darwin10
Thread model: posix
Source rev is 125326
$ make
llvm[1]: Compiling APFloat.cpp for Release build
llvm[1]: Compiling APInt.cpp for Release build
llvm[1]: Compiling APSInt.cpp for Release build
llvm[1]: Compiling Allocator.cpp for Release build
llvm[1]:
2014 Oct 18
3
[LLVMdev] Performance regression on ARM
Hi Chandler,
That's embarrassing how weird this part of clang is. I have a provisional
patch which fixes the problem but underlines clang's problems. I will
submit it tonight for comments.
суббота, 18 октября 2014 г. пользователь Chandler Carruth написал:
>
> On Fri, Oct 17, 2014 at 7:51 AM, Anton Korobeynikov <
> anton at korobeynikov.info
>