Skip to content

Conversation

frabert
Copy link
Collaborator

@frabert frabert commented Aug 20, 2025

No description provided.

@frabert frabert requested a review from Jezurko August 20, 2025 12:52
@Jezurko
Copy link
Collaborator

Jezurko commented Aug 21, 2025

Hm, I don't understand why is this necessary? Is this a bug in upstream? Or an issue specific to us?

@frabert
Copy link
Collaborator Author

frabert commented Aug 21, 2025

Hrmm I guess it would make sense to try and upstream this 🤔

Basically I've encountered things like

"llvm.func"() <{CConv = #llvm.cconv<ccc>, arg_attrs = [{llvm.alignstack = 8 : i64, llvm.noundef}], dso_local, frame_pointer = #llvm.framePointerKind<"non-leaf">, function_type = !llvm.func<void (array<2 x f64>)>, linkage = #llvm.linkage<external>, no_inline, no_unwind, optimize_none, passthrough = [["uwtable", "2"], ["no-trapping-math", "true"], ["stack-protector-buffer-size", "8"], ["target-cpu", "generic"]], sym_name = "emit", target_cpu = "generic", target_features = #llvm.target_features<["+fp-armv8", "+neon", "+outline-atomics", "+v8a", "-fmv"]>, visibility_ = 0 : i64}> ({

where the attr is applied to an array, which is apparently fine in LLVM but considered invalid in the LLVM MLIR dialect

@Jezurko
Copy link
Collaborator

Jezurko commented Aug 21, 2025

Oh, yeah. In that case I would probably vote for making an upstream PR and then backporting it to our repo? I think we should avoid diverging from upstream in these cases, to make our life simpler (and at least we get a little bit of street cred for contributing)

@frabert frabert changed the base branch from main to backup-20250828 September 11, 2025 13:18
@frabert frabert marked this pull request as draft September 15, 2025 14:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants