The disassemble function does more harm than good and is often the
most often broken function after an LLVM update. Shouldn't we remove
it to make our lives easier?
Marek
On Wed, May 27, 2015 at 7:27 AM, Vinson Lee v...@freedesktop.org wrote:
TargetOptions::NoFramePointerElim was removed in
I use this sometimes for debugging things in llvmpipe, so I don't think
that's a good option. Without it getting the actual assembly of the
shaders would be quite annoying.
It is unfortunately true that (due to the heavy use of the unstable C++
API) it breaks very often, but as long as it isn't
For the record, we also feel the pain, and I did look into the LLVM C
API for disassembly, but the problem is that we only get the function
start address -- we don't know where it finishes --, and the LLVM C API
doesn't expose enough capabilities to describe jump/return instructions,
which we
Am 28.05.2015 um 14:28 schrieb Jose Fonseca:
For the record, we also feel the pain, and I did look into the LLVM C
API for disassembly, but the problem is that we only get the function
start address -- we don't know where it finishes --, and the LLVM C API
doesn't expose enough capabilities to
On Tue, May 26, 2015 at 10:27:34PM -0700, Vinson Lee wrote:
TargetOptions::NoFramePointerElim was removed in llvm-3.7.0svn r238244
Remove NoFramePointerElim and NoFramePointerElimOverride from
TargetOptions and remove ExecutionEngine's dependence on CodeGen. NFC.
Reviewed-by: Tom Stellard
TargetOptions::NoFramePointerElim was removed in llvm-3.7.0svn r238244
Remove NoFramePointerElim and NoFramePointerElimOverride from
TargetOptions and remove ExecutionEngine's dependence on CodeGen. NFC.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
