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

Internal compiler error using reduce_by_index with copy dest as values #2058

Closed
spaarmann opened this issue Dec 7, 2023 · 2 comments
Closed
Assignees

Comments

@spaarmann
Copy link
Collaborator

This code

entry problem [n] (arr: *[n]i64) : [n]i64 =
  reduce_by_index arr (+) 0 (iota n) (copy arr)

produces the following output when compiled with futhark cuda or futhark opencl:

Internal compiler error.  Please report this:
  https://github.com/diku-dk/futhark/issues
Type error after pass 'simplify':
In function entry_problem
When checking function body
In expression of statement
  {defunc_0_reduce_by_index_res_5267 : ({}, [n_5216]i64)}
Type error:
Variable arr_5217 referenced after being consumed.

futhark c works fine.

Tested on a recent nightly (0.26.0 (prerelease), git: 07fa0b447debb1501c3bc9593a4f0975685bc8eb) as well as 0.25.9.

I originally came across this working on the 2nd weekly assignment for DPP'23, the example above is what I reduced it to. Cosmin proposed in the lab that the copy was incorrectly eliminated by some optimization and suggested using something like map (+ (opaque 0)) arr instead of copy arr as a workaround, which does work.

@nhey
Copy link
Member

nhey commented Dec 8, 2023

I suspected this might be my fault, but the following change makes it fail also on v0.22.6. (Just reporting this in case it's useful for pinpointing the problem.)

entry problem [n] (arr: *[n]i64) : [n]i64 =
  let arr2 = copy arr
  in reduce_by_index arr (+) 0 (iota n) arr2

A prettier workaround for you would be to copy first, I think.

entry problem [n] (arr: *[n]i64) : [n]i64 =
  reduce_by_index (copy arr) (+) 0 (iota n) arr

@athas athas self-assigned this Dec 8, 2023
@athas
Copy link
Member

athas commented Dec 8, 2023

I'm OK with blaming Nikolaj if no one else volunteers.

@athas athas closed this as completed in 730f7b0 Dec 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants