Displaying 4 results from an estimated 4 matches for "reg23".
Did you mean:
reg2
2016 Sep 21
3
Propagation of debug information for variable into basic blocks.
Adrian,
I am currently investigating issues where variables that one would expect to be available in a debugger are not in code that is compiled at optimisations other than -O0
The main problem appears to be with the LiveDebugValues::join() method because it does not allow variables to be propagated into blocks unless all predecessor blocks have an Outgoing Location for that variable.
As a
2016 Sep 21
2
Propagation of debug information for variable into basic blocks.
...ttice
>
> ⊥ (uninitialized / don't know)
> / \
> true false (is (not) available)
>
> where join(x, ⊥) = x, otherwise it behaves like boolean &.
>
> All debug variable values are initialized to the bottom element first.
> After processing BB#0 we have var[b, reg23] = true. When we join this with
> the unknown ⊥ from BB#1, we propagate var[b, reg23] into BB#1. Next time we
> join at BB#2 we will have consistent information in both predecessors and
> the algorithm converges.
FWIW: GCC does this as a union, so you get the maximal info available. If...
2009 Oct 22
0
[LLVMdev] request for help writing a register allocator
On Wed, 21 Oct 2009, Lang Hames wrote:
> There are any number of things that can go wrong in register allocation, so
> it's hard for me to guess without seeing your code.
>
> Possible issues:
>
> 2) How are you making sure that interfering virtregs never receive the same
> physreg? If you're using the LiveIntervals analysis (and the
>
2009 Oct 22
4
[LLVMdev] request for help writing a register allocator
Hi Susan,
> 1. I tried running the PBQP allocator (as a dynamic pass), but that didn't
> work....
Can you tell from this what I'm doing wrong?
>
The PBQP allocator is built into the LLVM CodeGen library, so the
"-regalloc=pbqp" option is already available in llc. If you've built a copy
of the PBQP allocator in a separate library it will try to re-register