Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uncommenting unused variable assignment (or other various things) gives different results #29983

Closed
KristofferC opened this issue Nov 9, 2018 · 3 comments
Assignees
Labels
kind:bug Indicates an unexpected problem or unintended behavior

Comments

@KristofferC
Copy link
Sponsor Member

KristofferC commented Nov 9, 2018

Using the code

using ForwardDiff: Dual
using StaticArrays

v = ((1.,2.), (2.,3.))

function f(x::Vector{T}) where {T}
    x1 = SVector((x[1],)) # comment this to get correct result
    la1 = SVector((x[1],))
    f1 = zero(SVector{1}) # can also initialize with zero(SVector{1, T}) to get correct result 
    for _ in v
        f1 += la1
        @show f1
    end
    return f1
end

x = [Dual(1.0,1.0)]
@show f(x)

gives the erroneous output:

f1 = Dual{Nothing,Float64,1}[Dual{Nothing}(1.0,1.0)]
f1 = Dual{Nothing,Float64,1}[Dual{Nothing}(1.0,1.0)]
f(x) = Dual{Nothing,Float64,1}[Dual{Nothing}(1.0,1.0)]

Now, we comment out the line x1 = SVector((x[1],))

f1 = Dual{Nothing,Float64,1}[Dual{Nothing}(1.0,1.0)]
f1 = Dual{Nothing,Float64,1}[Dual{Nothing}(2.0,2.0)]
f(x) = Dual{Nothing,Float64,1}[Dual{Nothing}(2.0,2.0)]

and get the correct result.

Executing the original code in the REPL also gives the correct result

julia> let
           x1 = SVector((x[1],))
           la1 = SVector((x[1],))
           f1 = zero(SVector{1})
           for _ in v
               f1 += la1
               @show f1
           end
           f1
       end
f1 = Dual{Nothing,Float64,1}[Dual{Nothing}(1.0,1.0)]
f1 = Dual{Nothing,Float64,1}[Dual{Nothing}(2.0,2.0)]
1-element SArray{Tuple{1},Dual{Nothing,Float64,1},1,1}:
 Dual{Nothing}(2.0,2.0)

If we initialize f1 to be of type T we also get correct result.

My guess it is something with the type instability in combination with broadcasting in combination with optimization but not sure...

@KristofferC KristofferC added the kind:bug Indicates an unexpected problem or unintended behavior label Nov 9, 2018
@KristofferC KristofferC changed the title Uncommenting unused variable assignment gives different results Uncommenting unused variable assignment (or other various things) gives different results Nov 9, 2018
@KristofferC
Copy link
Sponsor Member Author

Bump, anything I can do here to help?

@StefanKarpinski
Copy link
Sponsor Member

@Keno, I speculatively assigned this to you, assuming this was an optimizer bug.

@Keno
Copy link
Member

Keno commented Jan 5, 2019

Looks like an SROA bug that then gives LLVM license to do the wrong thing

Keno added a commit that referenced this issue Jan 5, 2019
SROA was accidentally treating a pending node as old and thus
getting the wrong type when querying the predecessor. As a result
it thought one of the paths was unreachable causing udefined data
to be introduced on that bath (generally the 1.0 that happened to
already be in register).
Keno added a commit that referenced this issue Jan 5, 2019
I don't have concrete tests for these, but it looks like
they all need the `is_old` predicate for what they're doing,
so switch those over also while we're at it.
Keno added a commit that referenced this issue Jan 5, 2019
SROA was accidentally treating a pending node as old and thus
getting the wrong type when querying the predecessor. As a result
it thought one of the paths was unreachable causing undefined data
to be introduced on that path (generally the `1.0` that happened to
already be in register).
Keno added a commit that referenced this issue Jan 5, 2019
I don't have concrete tests for these, but it looks like
they all need the `is_old` predicate for what they're doing,
so switch those over also while we're at it.
Keno added a commit that referenced this issue Jan 7, 2019
SROA was accidentally treating a pending node as old and thus
getting the wrong type when querying the predecessor. As a result
it thought one of the paths was unreachable causing undefined data
to be introduced on that path (generally the `1.0` that happened to
already be in register).

Fix #29983
Keno added a commit that referenced this issue Jan 7, 2019
I don't have concrete tests for these, but it looks like
they all need the `is_old` predicate for what they're doing,
so switch those over also while we're at it.
@Keno Keno closed this as completed in da0179c Jan 7, 2019
Keno added a commit that referenced this issue Jan 7, 2019
I don't have concrete tests for these, but it looks like
they all need the `is_old` predicate for what they're doing,
so switch those over also while we're at it.
KristofferC pushed a commit that referenced this issue Jan 9, 2019
SROA was accidentally treating a pending node as old and thus
getting the wrong type when querying the predecessor. As a result
it thought one of the paths was unreachable causing undefined data
to be introduced on that path (generally the `1.0` that happened to
already be in register).

Fix #29983

(cherry picked from commit da0179c)
KristofferC pushed a commit that referenced this issue Jan 9, 2019
I don't have concrete tests for these, but it looks like
they all need the `is_old` predicate for what they're doing,
so switch those over also while we're at it.

(cherry picked from commit 34f7a4a)
@KristofferC KristofferC mentioned this issue Jan 11, 2019
53 tasks
KristofferC pushed a commit that referenced this issue Jan 11, 2019
SROA was accidentally treating a pending node as old and thus
getting the wrong type when querying the predecessor. As a result
it thought one of the paths was unreachable causing undefined data
to be introduced on that path (generally the `1.0` that happened to
already be in register).

Fix #29983

(cherry picked from commit da0179c)
KristofferC pushed a commit that referenced this issue Jan 11, 2019
I don't have concrete tests for these, but it looks like
they all need the `is_old` predicate for what they're doing,
so switch those over also while we're at it.

(cherry picked from commit 34f7a4a)
@KristofferC KristofferC mentioned this issue Feb 4, 2019
39 tasks
KristofferC pushed a commit that referenced this issue Feb 4, 2019
SROA was accidentally treating a pending node as old and thus
getting the wrong type when querying the predecessor. As a result
it thought one of the paths was unreachable causing undefined data
to be introduced on that path (generally the `1.0` that happened to
already be in register).

Fix #29983
KristofferC pushed a commit that referenced this issue Feb 4, 2019
I don't have concrete tests for these, but it looks like
they all need the `is_old` predicate for what they're doing,
so switch those over also while we're at it.
KristofferC pushed a commit that referenced this issue Feb 4, 2019
SROA was accidentally treating a pending node as old and thus
getting the wrong type when querying the predecessor. As a result
it thought one of the paths was unreachable causing undefined data
to be introduced on that path (generally the `1.0` that happened to
already be in register).

Fix #29983
KristofferC pushed a commit that referenced this issue Feb 4, 2019
I don't have concrete tests for these, but it looks like
they all need the `is_old` predicate for what they're doing,
so switch those over also while we're at it.
KristofferC pushed a commit that referenced this issue Feb 11, 2019
SROA was accidentally treating a pending node as old and thus
getting the wrong type when querying the predecessor. As a result
it thought one of the paths was unreachable causing undefined data
to be introduced on that path (generally the `1.0` that happened to
already be in register).

Fix #29983
KristofferC pushed a commit that referenced this issue Feb 11, 2019
I don't have concrete tests for these, but it looks like
they all need the `is_old` predicate for what they're doing,
so switch those over also while we're at it.
KristofferC pushed a commit that referenced this issue Feb 11, 2019
SROA was accidentally treating a pending node as old and thus
getting the wrong type when querying the predecessor. As a result
it thought one of the paths was unreachable causing undefined data
to be introduced on that path (generally the `1.0` that happened to
already be in register).

Fix #29983
KristofferC pushed a commit that referenced this issue Feb 11, 2019
I don't have concrete tests for these, but it looks like
they all need the `is_old` predicate for what they're doing,
so switch those over also while we're at it.
KristofferC pushed a commit that referenced this issue Feb 11, 2019
SROA was accidentally treating a pending node as old and thus
getting the wrong type when querying the predecessor. As a result
it thought one of the paths was unreachable causing undefined data
to be introduced on that path (generally the `1.0` that happened to
already be in register).

Fix #29983
KristofferC pushed a commit that referenced this issue Feb 11, 2019
I don't have concrete tests for these, but it looks like
they all need the `is_old` predicate for what they're doing,
so switch those over also while we're at it.
KristofferC pushed a commit that referenced this issue Apr 20, 2019
SROA was accidentally treating a pending node as old and thus
getting the wrong type when querying the predecessor. As a result
it thought one of the paths was unreachable causing undefined data
to be introduced on that path (generally the `1.0` that happened to
already be in register).

Fix #29983
KristofferC pushed a commit that referenced this issue Apr 20, 2019
I don't have concrete tests for these, but it looks like
they all need the `is_old` predicate for what they're doing,
so switch those over also while we're at it.
KristofferC pushed a commit that referenced this issue Feb 20, 2020
SROA was accidentally treating a pending node as old and thus
getting the wrong type when querying the predecessor. As a result
it thought one of the paths was unreachable causing undefined data
to be introduced on that path (generally the `1.0` that happened to
already be in register).

Fix #29983
KristofferC pushed a commit that referenced this issue Feb 20, 2020
I don't have concrete tests for these, but it looks like
they all need the `is_old` predicate for what they're doing,
so switch those over also while we're at it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

No branches or pull requests

3 participants