support wide ints in tape

[motabbara]

Fixes #998

[codecov-commenter]

Codecov Report

Patch coverage: 58.33% and project coverage change: +0.03% 🎉

Comparison is base (5d310e8) 77.41% compared to head (6a4039f) 77.44%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1002      +/-   ##
==========================================
+ Coverage   77.41%   77.44%   +0.03%     
==========================================
  Files          19       19              
  Lines        8897     8909      +12     
==========================================
+ Hits         6888     6900      +12     
  Misses       2009     2009              

Files Changed	Coverage Δ
src/compiler.jl	78.22% <58.33%> (+0.04%)	⬆️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[wsmoses]

I'm a little worried that the mismatch here of int28->tuple of int8's may create an error similar to #999

[wsmoses]

I suppose we can turn this into an error then and just make our own primitive type for any other type we see. I kind of assume we won’t get arbitrary bit widths so having at most a few extra seems fine to me.

…

On Mon, Aug 21, 2023 at 2:56 PM Mo Tabbara ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/compiler.jl <#1002 (comment)>: > @@ -6101,7 +6103,24 @@ function to_tape_type(Type::LLVM.API.LLVMTypeRef)::Tuple{DataType,Bool} elseif N == 128 return UInt128, false else - error("Can't construct tape type for integer of width $N") + T = get(WideTypes, N, nothing) + if isnothing(T) + symname = Symbol(:UInt,N) + emptysvec = Core.svec() + _module = Main + Tp = ***@***.*** emptysvec symname @CCall jl_new_primitivetype(symname::Symbol, Because eval cannot be used in a generated function and we're inside one at this point. I guess the ccall shouldn't really be valid for the same reason. A bit stuck here unless we can go back to returning NTuple{N >> 6, UInt64} for N > 128. The only way to get to that branch in Julia is from new primitive types and there are no architectures that Julia supports where anything larger than i128 is supported so I don't think this impacts anything that has the possibility of performing arithmetic. — Reply to this email directly, view it on GitHub <#1002 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJTUXDF5XLETDZKT6CAAODXWLZ7NANCNFSM6AAAAAA3Q44D4I> . You are receiving this because you commented.Message ID: <EnzymeAD/Enzyme. ***@***.***>

[motabbara]

I suppose we can turn this into an error then and just make our own primitive type for any other type we see. I kind of assume we won’t get arbitrary bit widths so having at most a few extra seems fine to me.
…

I've changed to that approach now.