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
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 r
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 pos
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 wrote:
> TargetOptions::NoFramePointerElim was removed in llvm-3.7.0svn r238244
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 Stella
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
---
src/gallium/auxiliary/gallivm/lp_bld_debug.cpp | 2 ++
src/g
