[polly] r281052 - FlattenAlgo: Ensure we _really_ obtain a param space

[Tobias Grosser via llvm-commits]

Thank you.

On Sat, Sep 10, 2016, at 05:32 PM, Michael Kruse wrote:
> I can reproduce the problem with BUILD_SHARED_LIBS=ON. I'll look into it.
> 
> Michael
> 
> 
> 
> 2016-09-10 7:59 GMT+02:00 Tobias Grosser <tobias at grosser.es>:
> > On Sat, Sep 10, 2016, at 12:10 AM, Michael Kruse via llvm-commits wrote:
> >> 2016-09-09 22:22 GMT+02:00 Tobias Grosser via llvm-commits
> >> <llvm-commits at lists.llvm.org>:
> >> > On Fri, Sep 9, 2016, at 06:50 PM, Tobias Grosser via llvm-commits wrote:
> >> >> On Fri, Sep 9, 2016, at 06:37 PM, Michael Kruse via llvm-commits wrote:
> >> >> > Thank you for finding a fix.
> >> >> >
> >> >> > This is somewhat strange. Isn't isl_union_map_get_space defined to
> >> >> > return a parameter space?
> >> >>
> >> >> Right.
> >> >>
> >> >> > What is different on those machines where it
> >> >> > happened?
> >> >>
> >> >> They are owned by me. Seriously, I have no idea. This is very strange. I
> >> >> spent 30 minutes to look into this but was not able to find anything
> >> >> useful. :(
> >> >
> >> > OK. I spent a couple of hours to look into this. No idea what is going
> >> > on still. I was first suspecting the new C++ interface to incorrectly
> >> > free/deallocate memory. However, I could not find any issue and valgrind
> >> > also does not report anything.
> >> >
> >> > Then I just went to printf debugging. I attach you both my patch and the
> >> > typescript.
> >> >
> >> > The interesting piece is this:
> >> >
> >> > checkFlatten - SPtr: 18302032
> >> > checkFlatten - isParams :  is_params: space 18298960
> >> >  a
> >> >  b
> >> > space->tuple_id[0] 8021840
> >> > isl_id_none 8021840
> >> >  c
> >> >  d
> >> > 1
> >> > copy
> >> > Take ownership: 0
> >> > Move That2
> >> > copy
> >> > flattenSchedule - SchedulePtr: 18302032
> >> > flattenSchedule - isParams:  is_params: space 18298960
> >> >  a
> >> >  b
> >> > space->tuple_id[0] 8021840
> >> > isl_id_none 140647671602904
> >> >
> >> > The schedule remains the same when moving into flattenSchedule and the
> >> > space as well, even the id in space->tuple_id[0]. However, it seems the
> >> > address of the global isl_id_none changes. I tried to run this in gdb
> >> > and run 'watch  isl_id_none', but do not observe any change. I would
> >> > expect this address to stay constant at all times. I feel as if I missed
> >> > something very basic. Any idea what is going on?
> >>
> >> Thank you for your debugging efforts. This is as puzzling for me as for
> >> you.
> >>
> >> If the code is not compiled using -fpic, "&isl_id_none" should turn
> >> into a constant.
> >>
> >> 0115E1A6  push        offset isl_id_none (01441810h)
> >> 0115E1AB  push        1426678h
> >> 0115E1B0  call        _printf (0E6E9C5h)
> >> 0115E1B5  add         esp,8
> >> (MSVC 32-bit disassembly, debug build)
> >>
> >> With -fpic, it becomes relative to the instruction pointer (%rip)
> >>
> >>    0x00000000004e73b1 <+129>:   lea    0x2bd2e8(%rip),%rbp        #
> >> 0x7a46a0 <isl_id_none>
> >>    0x00000000004e73b8 <+136>:   lea    0x86d14(%rip),%rsi        #
> >>    0x56e0d3
> >>    0x00000000004e73bf <+143>:   xor    %eax,%eax
> >>    0x00000000004e73c1 <+145>:   mov    $0x1,%edi
> >>    0x00000000004e73c6 <+150>:   mov    %rbp,%rdx
> >>    0x00000000004e73c9 <+153>:   callq  0x404730 <__printf_chk at plt>
> >> (gdb 64-bit disassembly, release build)
> >>
> >>
> >> Your new address 0x7FEB16811ED8 (140647671602904) would indicate a
> >> location on the stack. With this code, I have no idea how this could
> >> print different values in the middle of the program's execution
> >> (except the loader decided to relocate the .text section while
> >> running?!?)
> >>
> >> If you are interested into looking further into it, you could try to
> >> compile without -fpic. Or debug with gdb until before it changes, step
> >> forward while observing &isl_id_none, maybe even tracking it through
> >> the registers. Does gdb even evaluate it to the same value as printf
> >> prints? Btw, 'watch  isl_id_none' would observe isl_id_none's
> >> contents, not its address.
> >
> > Hi Michael,
> >
> > I just set BUILD_SHARED_LIBS=OFF and the issue disappeared even for the
> > original code without my (isl_space_params "fix"). Can you reproduce
> > this on linux with BUILD_SHARED_LIBS=ON?
> >
> > Best,
> > Tobias