Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] Clarification regarding the LLVM IR."
2014 May 29
4
[LLVMdev] Proposal: "load linked" and "store conditional" atomic instructions
Hi,
I've been looking at improving atomicrmw & cmpxchg code more,
particularly on architectures using the load-linked/store-conditional
model.
The summary is that current expansion for cmpxchg seems to happen too
late for LLVM to make meaningful use of the opportunities it provides.
I'd like to move it earlier and express it in terms of a first-class
pair of "load linked"
2014 May 29
3
[LLVMdev] Proposal: "load linked" and "store conditional" atomic instructions
Hi Philip,
On 29 May 2014 17:03, Philip Reames <listmail at philipreames.com> wrote:
> I have some reservations about this proposal. I don't have anything
> particularly concrete, but the idea of supporting both LL/SC and atomicrwm
> in the IR concerns me from a complexity perspective.
Well, I'll start by saying my particular optimisation use case looks
like it's not
2015 Apr 24
3
[LLVMdev] Floating point atomic load and add
Quoting Tim Northover <t.p.northover at gmail.com>:
> On 24 April 2015 at 13:53, Tyler Denniston <tyler at csail.mit.edu> wrote:
>> I'm wondering how I can create an atomic load and add instruction for
>> floating point values. If I use IRBuilder::CreateAtomicRMW() I get the
>> error message: "atomicrmw operand must have integer type".
>
>
2013 May 14
2
[LLVMdev] Keeping Clang from changing function calls to IR operations: cmpxchg
I'm working on getting the LLVM/projects/Test-Suite/UnitTest to compile for
a target that I am developing.
There is an example: AtomicOps, that uses calls to:
__sync_fetch_and_add
__sync_val_compare_and_swap
__sync_lock_test_and_set
These get converted into llvm IR operations like:
atomicrmw
cmpxchg
Is there any way to keep these as function calls, as they are easier to map
to the
2018 Jun 13
12
RFC: Atomic LL/SC loops in LLVM revisited
# RFC: Atomic LL/SC loops in LLVM revisited
## Summary
This proposal gives a brief overview of the challenges of lowering to LL/SC
loops and details the approach I am taking for RISC-V. Beyond getting feedback
on that work, my intention is to find consensus on moving other backends
towards a similar approach and sharing common code where feasible. Scroll down
to 'Questions' for a summary
2013 Jun 28
3
[LLVMdev] Question regarding the x86 SBB instruction.
Hi,
I have the x86 SBB instruction. how should I represent this in LLVM
IR. (as part of a decompiler from binary to LLVM IR)
Pre-conditions:
%eax = 0xffffffff
%edx = 0xffffffff
%carry = 1
SBB %eax, %edx // %edx is the destination doing %edx = %edx -
(%eax + carry)
JC jump_destination1 // If the Carry flag is set, jump to jump_destination1
How do I represent this correctly in LLVM
2013 Jun 28
0
[LLVMdev] Question regarding the x86 SBB instruction.
Look at the __builtin_addc* builtins in clang. I am currently working on an optimization which transforms said intrinsics into chains of ADCs/SBBs.
Michael
On Jun 28, 2013, at 5:51 AM, James Courtier-Dutton <james.dutton at gmail.com> wrote:
> Hi,
>
> I have the x86 SBB instruction. how should I represent this in LLVM
> IR. (as part of a decompiler from binary to LLVM IR)
2013 Mar 12
4
[LLVMdev] help decompiling x86 ASM to LLVM IR
On 12 March 2013 16:39, Óscar Fuentes <ofv at wanadoo.es> wrote:
>
> This is not possible, except for specific cases.
>
> Consider this code:
>
> long foo(long *p) {
> ++p;
> return *p;
> }
>
> The X86 machine code would do something like
>
> add %eax, 4
>
> for `++p', but for x86_64 it would be
>
> add %rax, 8
>
> But you
2017 Jan 19
4
[RFC] IR-level Region Annotations
Hi Johannes,
> I am especially curious where you get your data from. Tapir [0] (and to
> some degree PIR [1]) have shown that, counterintuitively, only a few changes
> to LLVM passes are needed. Tapir was recently used in an MIT class with a
> lot of students and it seemed to work well with only minimal changes
> to analysis and especially transformation passes.
TAPIR is an
2013 Mar 12
6
[LLVMdev] help decompiling x86 ASM to LLVM IR
Hi,
I am looking to decompile x86 ASM to LLVM IR.
The original C is this:
int test61 ( unsigned value ) {
int ret;
if (value < 1)
ret = 0x40;
else
ret = 0x61;
return ret;
}
It compiles with GCC -O2 to (rather cleverly removing any branches):
0000000000000000 <test61>:
0: 83 ff 01 cmp $0x1,%edi
3:
2015 Dec 11
2
RFC: Extending atomic loads and stores to floating point and vector types
On 12/11/2015 01:29 PM, James Y Knight wrote:
>
> On Fri, Dec 11, 2015 at 3:05 PM, Philip Reames via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>> One open question I don't know the answer to: Are there any
>> special semantics required from floating point stores which
>> aren't met
2018 Aug 28
2
Execute / Interpret LLVM IR Bitcode
Hi,
I know their are various tools that can take LLVM IR Bitcode and JIT
it and execute it.
Is there anything that can do the equivalent but at the LL\VM IR Bitcode level?
So, that for example, I could set some initial conditions, and then
single step through the IR Bitcode function, and pause it and print
out any of the SSA values that I wish?
Kind Regards
James
2015 Apr 24
4
[LLVMdev] Floating point atomic load and add
Hello,
I'm wondering how I can create an atomic load and add instruction for
floating point values. If I use IRBuilder::CreateAtomicRMW() I
get the error message: "atomicrmw operand must have integer type".
I am using LLVM 3.4 and the only system I need to support is x86.
2013 Mar 12
0
[LLVMdev] help decompiling x86 ASM to LLVM IR
James Courtier-Dutton <james.dutton at gmail.com> writes:
> I am looking to decompile x86 ASM to LLVM IR.
> The original C is this:
> int test61 ( unsigned value ) {
> int ret;
> if (value < 1)
> ret = 0x40;
> else
> ret = 0x61;
> return ret;
> }
>
> It compiles with GCC -O2 to (rather
2020 Apr 16
2
Various Intermediate Representations. IR
On Wed, 15 Apr 2020 at 17:28, David Blaikie <dblaikie at gmail.com> wrote:
>
> opaque pointers don't exist in the IR yet - the goal is to reduce the places that use non-opacity of pointer types already/today and then opacify the existing pointer type, rather than introducing an opaque pointer type & having it concurrently with non-opaque pointer types. (though in retrospect
2014 Jun 22
2
[LLVMdev] Clarification on the backward compatibility promises
Does anyone have anything else to say about .bc/.ll compatibility? It is
important to be clear to users about what compatibility we provide. I'd
like to get consensus about this and put it in the docs somewhere.
-- Sean Silva
On Wed, Jun 18, 2014 at 11:15 AM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
>
> On Wed, Jun 18, 2014 at 10:35 AM, Tim Northover
2020 Apr 14
3
Various Intermediate Representations. IR
Hi,
I am looking for an IR that is similar to LLVM IR, with its SSA form,
module->function->block->instruction etc.
But, I wish a much reduced type model.
I wish only three types:
1) An Integer of various bit-widths.
2) A pointer, but a pointer that does not need to point to a known
type. A sort of "pointer to unknown type".
3) Floats of various varieties.
For example, if we
2013 Mar 12
0
[LLVMdev] help decompiling x86 ASM to LLVM IR
On 3/12/2013 11:55 AM, James Courtier-Dutton wrote:
> I already know how to handle the case you describe.
> I am not converting ASM to LLVM IR without doing quite a lot of analysis first.
> 1) I can already tell if a register is refering to a pointer or an
> integer based on how it is used. Does it get de-referenced or not? So,
> I would know that "p" is a pointer.
What if
2008 Oct 14
3
Server settings for BackgrounDRB?
I have backgroundrb working locally and everything''s fine. However, i
can''t get it running on our server.
I read a blog post by David Burger about backgroundrb
(http://david-burger.blogspot.com/2008/04/backgroundrb-rails-notes.html#comment-form)
and it says that you set up your backgroundrb.yml file with a different
section for each environment you want to use. Mine looks like
2008 Jun 30
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Chris Lattner wrote:
> On Jun 27, 2008, at 8:27 AM, Gary Benson wrote:
> > def CMP_UNRESw : Pseudo<(outs), (ins GPRC:$rA, GPRC:$rB, i32imm:
> > $label),
> > "cmpw $rA, $rB\n\tbne- La${label}_exit",
> > [(PPCcmp_unres GPRC:$rA, GPRC:$rB, imm:
> > $label)]>;
> > }
> >
> > ...and