Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] -ffixed option in llvm-gcc"
2011 Mar 07
2
[LLVMdev] matching function call arguments
Hi Reid,
Thank you for your response. In my analysis, I will always have
entry(2) and exit(2). I will not run into cases involving entry (1+1) or
entry (fn return values). I am having trouble trying to compare the
arguments of entry and exit in the following scenario.
#include<stdio.h>
#include<stdlib.h>
#include<pthread.h>
struct sa
{
int a;
pthread_mutex_t *mutex1;
2011 Mar 07
0
[LLVMdev] matching function call arguments
Could you be more precise about what you mean by "identical"? Would
entry(2) and entry(1+1) be considered equivalent?
If the same Value* is passed to entry and exit, then pointer equality
(==) will detect that.
Reid
On Mon, Mar 7, 2011 at 8:08 AM, Hari Pyla <harip at vt.edu> wrote:
> Hi,
> I am trying to identify if two functions were called with exactly the same
2011 Mar 07
2
[LLVMdev] matching function call arguments
Hi,
I am trying to identify if two functions were called with exactly the same argument. For instance, in the below example, assuming both entry() and exit() functions take a single argument, I would like to know if arg1 in entry() is same as arg1in exit().
int a;
struct sa
{
int b;
int c;
};
int main ()
{
struct sa s;
entry (arg1);
...
exit (arg1);
return 0;
}
In
2011 Jan 05
0
[LLVMdev] force inlineing a function using opt
If I understand correctly, you're saying that the C source definition of the prologue function is declared as static. If you compile that function to LLVM IR, it will get interal linkage and will not be visible to functions in other compilation units; instead, it will get renamed if there is a function defined with the same name. As such, it will never get inlined as the instrumented code
2011 Jan 04
3
[LLVMdev] force inlineing a function using opt
Hi,
I am instrumenting the stores in a program by inserting a function
call (store_prologue) before every store instruction in the IR file. I
set the prologue function's attribute to "AlwaysInline" using
addFnAttr(). In the program the prologue function is defined as static
inline. I am using opt to generate an optimized (inline the calls to the
store prologue) using the
2012 Oct 02
2
[LLVMdev] adding support for -ffixed-<reg>
On 10/2/2012 9:36 AM, 陳韋任 (Wei-Ren Chen) wrote:
> On Tue, Oct 02, 2012 at 09:23:27AM -0500, Matthew Curtis wrote:
>> I'm adding support for -ffixed-<reg> for Hexagon and was wondering if I should
>> do it in such a way that other targets get the support as well by default or if
>> a given target back-end should have to explicitly opt-in for support.
> What
2012 Oct 02
0
[LLVMdev] adding support for -ffixed-<reg>
On Tue, Oct 02, 2012 at 09:23:27AM -0500, Matthew Curtis wrote:
> I'm adding support for -ffixed-<reg> for Hexagon and was wondering if I should
> do it in such a way that other targets get the support as well by default or if
> a given target back-end should have to explicitly opt-in for support.
What "-ffixed-<reg>" does?
Regards,
chenwj
--
Wei-Ren Chen
2012 Oct 03
2
[LLVMdev] adding support for -ffixed-<reg>
Hi Chris,
> From the design perspective, I think it would make sense to represent this in
> LLVM IR with named metadata (http://llvm.org/docs/LangRef.html#
> namedmetadatastructure) like "!llvm.fixedregs". This could then be picked up
> by the code generator, installed as preallocated registers (Jakob would be the
> one to ask how best to do this).
-ffixed-<reg>
2012 Oct 02
5
[LLVMdev] adding support for -ffixed-<reg>
I'm adding support for -ffixed-<reg>
<http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Code-Gen-Options.html#index-ffixed-1435>
for Hexagon and was wondering if I should do it in such a way that other
targets get the support as well by default or if a given target back-end
should have to explicitly opt-in for support.
Any opinions?
Matthew Curtis.
--
Qualcomm Innovation Center,
2012 Oct 03
0
[LLVMdev] adding support for -ffixed-<reg>
On Oct 2, 2012, at 7:23 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote:
> I'm adding support for -ffixed-<reg> for Hexagon and was wondering if I should do it in such a way that other targets get the support as well by default or if a given target back-end should have to explicitly opt-in for support.
It would be great to have this as a target-indepentent (well, obviously
2012 Oct 02
0
[LLVMdev] adding support for -ffixed-<reg>
> From the GCC manual (http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/
> Code-Gen-Options.html#index-ffixed-2267)
>
> -ffixed-reg
>
> Treat the register named reg as a fixed register; generated code should
> never refer to it (except perhaps as a stack pointer, frame pointer or in
> some other fixed role).
>
> reg must be the name of a register. The
2011 Mar 07
0
[LLVMdev] matching function call arguments
On Mon, Mar 7, 2011 at 8:03 PM, Hari Pyla <harip at vt.edu> wrote:
> Thank you for your response. In my analysis, I will always have
> entry(2) and exit(2). I will not run into cases involving entry (1+1) or
> entry (fn return values). I am having trouble trying to compare the
> arguments of entry and exit in the following scenario.
>
> #include<stdio.h>
>
2012 Oct 03
0
[LLVMdev] adding support for -ffixed-<reg>
On Oct 3, 2012, at 12:13 AM, 陳韋任 (Wei-Ren Chen) <chenwj at iis.sinica.edu.tw> wrote:
> Hi Chris,
>
>> From the design perspective, I think it would make sense to represent this in
>> LLVM IR with named metadata (http://llvm.org/docs/LangRef.html#
>> namedmetadatastructure) like "!llvm.fixedregs". This could then be picked up
>> by the code
2019 Jan 04
2
[RFC] Allocatable Global Register Variables for ARM
Thank you for your reply Eli,
I too was working with Carey on this feature, so please let me reply.
On 12/21/18 8:05 PM, Friedman, Eli via llvm-dev wrote:
> As a side-note, you might want to check that prologue/epilogue emission won't emit a PUSH/POP that refers to a register reserved this way; we sometimes add an "extra" register to align the stack.
Yes, you are right.
2008 Oct 31
3
[LLVMdev] gfortran link failure in current llvm svn
On Oct 30, 2008, at 11:02 PM, Chris Lattner wrote:
> On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote:
>> ps We do have one oddity left in llvm-gfortran from current llvm
>> svn. I find everytime I compile something with llvm-gfortran that
>> I get a series of warning messages...
>>
>> f951: warning: command line option "-Wformat" is valid for C/C++/
2013 Apr 01
1
XML error: missing security model on virsh migrate
Hi,
I am trying to migrate a VM from one node to another and I get the
following error message.
[user at n0 ~]$ virsh --c qemu:///system migrate --verbose
Fedora-17-x86_64-1 qemu+ssh://n1/system
error: XML error: missing security model when using multiple labels
On both the src and dest nodes, I've disabled SELinux and I have the
following libvirt version installed
$virsh --connect
2018 Dec 21
2
[RFC] Allocatable Global Register Variables for ARM
Hi all,
This is a RFC on support for Global Register Variables in the Arm backend.
Whilst there has been some prior discussion about whether or not LLVM should (or even needs to) support global register variables,
today there seems to be a good measure of support for this in both Clang+LLVM (although it is currently limited to SP).
When most of this support landed there was some concern
2001 Nov 13
3
Alpha compile warning
Getting this warning compiling on an alpha, is it a problem?
2.4.15-pre4
gcc -D__KERNEL__ -I/usr/users/donjr/linux-2.4.15-pre4/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mno-fp-regs -ffixed-8 -mcpu=ev5
-Wa,-mev6 -DEXPORT_SYMTAB -c journal.c
journal.c: In function `journal_init_inode':
journal.c:758: warning: long long
2019 May 14
4
Handling of the x18 register in Wine on AArch64
Hi,
I'm sending this discussion to both wine-devel and llvm-dev, to try to
keep the discussion open for both sides, to try to find a workable
compromise. This was preliminarily discussed on llvm-dev already a few
weeks ago.
One of the major unresolved issues with Wine for AArch64 is how to handle
the platform specific register x18.
(https://bugs.winehq.org/show_bug.cgi?id=38780) As
2019 Apr 26
10
Automatically backing up and restoring x18 around function calls on AArch64?
Hi,
When using Wine to run Windows ARM64 executables on Linux, there's one
major ABI incompatibility between the two; Windows treats the x18
register as the reserved platform register, while it is free to be
clobbered anywhere in code on Linux.
The Wine code sets up this register before passing control over to the
Windows executable code, but whenever the Windows code calls a function