# Projects

User does not belong to any projects.

# User Details

User Since
Mar 16 2019, 2:09 PM (166 w, 1 d)

# Mar 31 2022

I didn't realize this existed. thank you for the information.

Mar 31 2022, 9:49 PM · Restricted Project, Restricted Project
Tyker changed the visibility for D122863: [MLIR][cf] Add branch operand edition function to cf.cond_br.
Mar 31 2022, 9:09 PM · Restricted Project, Restricted Project
Tyker added reviewers for D122863: [MLIR][cf] Add branch operand edition function to cf.cond_br: .
Mar 31 2022, 9:08 PM · Restricted Project, Restricted Project
Tyker added a comment to D122863: [MLIR][cf] Add branch operand edition function to cf.cond_br.

is there interest in having this upstream ?
I am not sure how it should be tested upstream ?

Mar 31 2022, 9:07 PM · Restricted Project, Restricted Project
Tyker requested review of D122863: [MLIR][cf] Add branch operand edition function to cf.cond_br.
Mar 31 2022, 9:02 PM · Restricted Project, Restricted Project

# Nov 23 2021

This seems like a good change to me. but i don't think my approval is enough

Nov 23 2021, 9:34 AM · Restricted Project

# Oct 27 2021

Tyker added inline comments to D74130: [clang] fix consteval call in default arguments.
Oct 27 2021, 10:04 AM · Restricted Project
Tyker updated the diff for D74130: [clang] fix consteval call in default arguments.

FWIW, I am not seeing double errors on that code. Here's the output I get with this patch applied locally:

```F:\source\llvm-project>cat "C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp"
consteval int f1() { return 0; }
consteval auto g() { return f1; }

constexpr auto e = g();
constexpr auto e1 = f1;

F:\source\llvm-project>llvm\out\build\x64-Debug\bin\clang.exe -fsyntax-only -std=c++2b "C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp"
C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:4:20: error: call to consteval function 'g' is not a
constant expression
constexpr auto e = g();
^
C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:4:20: note: pointer to a consteval declaration is not a
constant expression
C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:1:15: note: declared here
consteval int f1() { return 0; }
^
C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:4:16: error: constexpr variable 'e' must be initialized
by a constant expression
constexpr auto e = g();
^   ~~~
C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:4:16: note: pointer to a consteval declaration is not a
constant expression
C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:1:15: note: declared here
consteval int f1() { return 0; }
^
C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:5:21: error: cannot take address of consteval function
'f1' outside of an immediate invocation
constexpr auto e1 = f1;
^
C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:1:15: note: declared here
consteval int f1() { return 0; }
^
C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:5:16: error: constexpr variable 'e1' must be initialized
by a constant expression
constexpr auto e1 = f1;
^    ~~
C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:5:16: note: pointer to a consteval declaration is not a
constant expression
C:\Users\aballman\OneDrive - Intel Corporation\Desktop\test.cpp:1:15: note: declared here
consteval int f1() { return 0; }
^
4 errors generated.```

These look like valid errors to me, so am I misunderstanding something? Is the concern that we're emitting error: constexpr variable '<whatever>' must be initialized by a constant expression after we already issued a diagnostic on the same line?

Oct 27 2021, 10:01 AM · Restricted Project

# Oct 21 2021

Tyker updated the diff for D74130: [clang] fix consteval call in default arguments.

@Tyker -- are you planning to pick this review back up again sometime in the near future? If not, do you care if the review gets commandeered?

here is an update that i think is close to committable. if it is not i am fine if it gets commandeered.

Oct 21 2021, 4:13 PM · Restricted Project

# Apr 1 2021

LGTM

Apr 1 2021, 9:37 AM · Restricted Project

seems good to me. but maybe other still have comments.

Apr 1 2021, 7:21 AM · Restricted Project

# Mar 15 2021

I think the process of checking is a value is noundef needs to be more general than just calls. maybe addKnowledge would be a better place.
because nonnull and align information can also be inferred from loads/stores.

Hi, sorry for my delay in response.
Could you elaborate a bit with an example, please?
Does it mean that the updated analysis may return suboptimal results?

Mar 15 2021, 10:18 AM · Restricted Project
Tyker added a comment to D90529: Allow nonnull/align attribute to accept poison.

A fix in AssumeBundleBuilder to make it comply LangRef: D98228

BTW, I found that "align" can take two operands: "align"(i8* ptr, i64 a, i64 b) What is the meaning of the second index (b)?

the meaning of the second index is the offset of the alignment. so with "align"(i8* ptr, i64 16, i64 12), ptr is aligned on 4 but ptr + 4 is aligned on 16.
I introduced this to support __builtin_assume_aligned which has similar semantics.

Hi, thanks for the info.

But I think an example in Transforms/AlignmentFromAssumptions/simple.ll conflicts with your definition. It has:

```28 define i32 @foo2a(i32* nocapture %a) nounwind uwtable readonly {
29 entry:
30   tail call void @llvm.assume(i1 true) ["align"(i32* %a, i32 32, i32 28)]
31   %arrayidx = getelementptr inbounds i32, i32* %a, i64 -1
32   %0 = load i32, i32* %arrayidx, align 4
33   ret i32 %0
34
35 ; CHECK-LABEL: @foo2a
36 ; CHECK: load i32, i32* {{[^,]+}}, align 32
37 ; CHECK: ret i32
38 }```

"align"(i32* %a, i32 32, i32 28) means %a + 4 is 32-bytes aligned, IIUC. Then, %a - 4 cannot be 32-bytes aligned, is it?

Yes, this looks like a bug.

Mar 15 2021, 8:20 AM · Restricted Project

# Mar 9 2021

I think the process of checking is a value is noundef needs to be more general than just calls. maybe addKnowledge would be a better place.
because nonnull and align information can also be inferred from loads/stores.

Mar 9 2021, 1:43 AM · Restricted Project
Tyker added a comment to D90529: Allow nonnull/align attribute to accept poison.

A fix in AssumeBundleBuilder to make it comply LangRef: D98228

BTW, I found that "align" can take two operands: "align"(i8* ptr, i64 a, i64 b) What is the meaning of the second index (b)?

Mar 9 2021, 1:41 AM · Restricted Project

# Mar 8 2021

Tyker added a comment to D96646: [NFC] update LangRef for D88645.

I'm not trying to be difficult, but I genuinely still don't understand the additional arguments pointer. Is it intended to allow proprietary extensions? Is there an example somewhere?

If these intrinsics are meant as a general mechanism to enable arbitrary communication between custom front ends and custom optimization passes, that's fine. I'd just like to see something explicitly explaining that.

Mar 8 2021, 9:39 AM · Restricted Project
Tyker updated the summary of D96646: [NFC] update LangRef for D88645.
Mar 8 2021, 9:39 AM · Restricted Project

# Mar 1 2021

Tyker updated the diff for D96646: [NFC] update LangRef for D88645.

Mar 1 2021, 5:52 AM · Restricted Project

# Feb 23 2021

Tyker updated the diff for D96646: [NFC] update LangRef for D88645.

fixed the sentence.

Feb 23 2021, 1:55 AM · Restricted Project

# Feb 15 2021

Tyker updated the diff for D96646: [NFC] update LangRef for D88645.

Feb 15 2021, 10:15 AM · Restricted Project

# Feb 13 2021

Feb 13 2021, 4:33 AM · Restricted Project
Feb 13 2021, 4:32 AM · Restricted Project

This seems good to me but i am not familiar the the auto-upgrader.

Feb 13 2021, 4:30 AM · Restricted Project

I added the changes to the langref in https://reviews.llvm.org/D96646

Feb 13 2021, 4:29 AM · Restricted Project, Restricted Project
Tyker requested review of D96646: [NFC] update LangRef for D88645.
Feb 13 2021, 4:28 AM · Restricted Project
Tyker committed rG642e9225c6e8: reland [InstCombine] convert assumes to operand bundles (authored by Tyker).
reland [InstCombine] convert assumes to operand bundles

# Feb 9 2021

Tyker committed rG5652e192fc22: Revert "[InstCombine] convert assumes to operand bundles" (authored by Tyker).
Revert "[InstCombine] convert assumes to operand bundles"
Feb 9 2021, 4:34 PM · Restricted Project
Tyker committed rG5eb2e994f9b3: [InstCombine] convert assumes to operand bundles (authored by Tyker).
[InstCombine] convert assumes to operand bundles
Feb 9 2021, 10:34 AM · Restricted Project

# Jan 30 2021

Tyker added inline comments to D82703: [InstCombine] convert assumes to operand bundles.
Jan 30 2021, 1:26 AM · Restricted Project
Tyker updated the diff for D82703: [InstCombine] convert assumes to operand bundles.

Jan 30 2021, 1:26 AM · Restricted Project

# Jan 16 2021

Tyker added inline comments to D82703: [InstCombine] convert assumes to operand bundles.
Jan 16 2021, 3:39 AM · Restricted Project
Tyker added inline comments to D82703: [InstCombine] convert assumes to operand bundles.
Jan 16 2021, 3:39 AM · Restricted Project
Tyker updated the diff for D82703: [InstCombine] convert assumes to operand bundles.

@Tyker are you going to upstream this? If not, can someone take over?

Jan 16 2021, 3:38 AM · Restricted Project

# Nov 11 2020

Just an FYI, but this probably should have gotten a review as it's not NFC (it changes what information gets dumped in text and JSON form, impacts AST matching behavior, and other minor effects). That said, overall the direction seems fine to me, though I did question one of the changes.

Tyker added a comment to D91239: Update attribute example to fit the new Annotation API.

I recently made it much easier to create AnnotationAttr in this context with https://reviews.llvm.org/rGd093401a2617d3c46aaed9eeaecf877e3ae1a9f1.

Nov 11 2020, 4:58 AM · Restricted Project

# Nov 9 2020

[NFC] Remove string parameter of annotation attribute from AST childs.

# Oct 27 2020

Looks like this broke tests: http://45.33.8.238/linux/31159/step_12.txt

Please take a look, and revert for now if it takes a while to fix.

this is fixed by 4afa077899b

Oct 27 2020, 2:30 AM · Restricted Project, Restricted Project
Tyker committed rG2618247c61c2: Correct examples after d3205bbca3e0002d76282878986993e7e7994779 (authored by Tyker).
Correct examples after d3205bbca3e0002d76282878986993e7e7994779

# Oct 26 2020

Try to fix buildbots after d3205bbca3e0002d76282878986993e7e7994779
[Annotation] Allows annotation to carry some additional constant arguments.
Oct 26 2020, 2:50 AM · Restricted Project, Restricted Project

# Oct 23 2020

LGTM aside from a request for a comment to be added. Thank you!

do you mean an RFC on llvm-dev/cfe-dev ?

Oh gosh no! I just meant I was asking for a comment to be added in SemaDeclAttr.td before you commit. Sorry for the confusion! :-)

Oct 23 2020, 3:37 AM · Restricted Project, Restricted Project

# Oct 22 2020

LGTM aside from a request for a comment to be added. Thank you!

Oct 22 2020, 9:43 AM · Restricted Project, Restricted Project

# Oct 21 2020

Tyker added a comment to D63640: [clang] Improve Serialization/Imporing of APValues.

but the "real" blocker is that the testing depends on D85144 for testing.
we could land it marking the tests XFAIL and correct it when dumping improvements arrive.

I'd be OK with that. We'll have coverage for this in various forms landing pretty soon.

Oct 21 2020, 10:06 AM · Restricted Project
Tyker committed rGcf34dd0c4e84: [clang] Improve Serialization/Imporing/Dumping of APValues (authored by Tyker).
[clang] Improve Serialization/Imporing/Dumping of APValues
Oct 21 2020, 10:04 AM · Restricted Project

# Oct 20 2020

Oct 20 2020, 4:30 AM · Restricted Project, Restricted Project

Oct 20 2020, 4:28 AM · Restricted Project, Restricted Project

# Oct 17 2020

Tyker added inline comments to D74130: [clang] fix consteval call in default arguments.
Oct 17 2020, 2:48 AM · Restricted Project
Tyker updated the diff for D74130: [clang] fix consteval call in default arguments.

Oct 17 2020, 2:48 AM · Restricted Project

# Oct 15 2020

Tyker updated the diff for D74130: [clang] fix consteval call in default arguments.

Oct 15 2020, 3:53 AM · Restricted Project
Tyker committed rG53122ce2b39f: [NFC] Correct name of profile function to Profile in APValue (authored by Tyker).
[NFC] Correct name of profile function to Profile in APValue
Oct 15 2020, 1:54 AM · Restricted Project
Tyker added a comment to D63640: [clang] Improve Serialization/Imporing of APValues.

Reverse ping: I have a patch implementing class type non-type template parameters

that's blocked on this landing. If you won't have time to address @martong's comments soon, do you mind if I take this over and land it?

Oct 15 2020, 12:28 AM · Restricted Project
Tyker updated the diff for D63640: [clang] Improve Serialization/Imporing of APValues.

try to apply martongs's suggestions.

Oct 15 2020, 12:27 AM · Restricted Project

# Oct 12 2020

What about leaving call llvm.assume whenever the load !noundef is moved to somewhere else? I guess this is what LLVM is doing as well.

If --enable-knowledge-retention is set, we should certainly do that if we would otherwise strip the metadata (not only for noundef).

this is not implemented the assume building currently don't look at any metadata.

Oct 12 2020, 1:41 PM · Restricted Project
Tyker added a comment to D89219: [ValueTracking] Use assume's noundef operand bundle.

you probably want to add noundef to isUsefullToPreserve such that it gets preserved automatically when knowledge retention is turned on.

Oct 12 2020, 1:15 PM · Restricted Project

# Oct 10 2020

Oct 10 2020, 3:18 PM · Restricted Project, Restricted Project

Oct 10 2020, 5:58 AM · Restricted Project, Restricted Project

# Oct 9 2020

Oct 9 2020, 6:25 AM · Restricted Project, Restricted Project

Oct 9 2020, 2:05 AM · Restricted Project, Restricted Project

# Oct 8 2020

This change makes a lot of sense, but i don't understand all the consequences either.

Oct 8 2020, 10:33 AM · Restricted Project

# Oct 1 2020

Oct 1 2020, 10:56 AM · Restricted Project
Tyker updated the diff for D63640: [clang] Improve Serialization/Imporing of APValues.

Oct 1 2020, 10:56 AM · Restricted Project
Oct 1 2020, 2:40 AM · Restricted Project, Restricted Project
Tyker requested review of D88643: [NFC] Correct name of profile function to Profile in APValue.
Oct 1 2020, 2:35 AM · Restricted Project

# Sep 26 2020

Tyker updated the diff for D82703: [InstCombine] convert assumes to operand bundles.

rebased

Sep 26 2020, 7:00 AM · Restricted Project

this was a mistake i intended to update D82703

Sep 26 2020, 6:59 AM · Restricted Project
Tyker requested review of D88358: [InstCombine][Assumes] Cannonicalize assumes in instcombine.
Sep 26 2020, 6:52 AM · Restricted Project
Tyker committed rG8d5b289a4681: [LoopDelete][Assume] Allow deleting loops with assumes (authored by Tyker).
[LoopDelete][Assume] Allow deleting loops with assumes
Tyker added a comment to D86816: [LoopDelete][Assume] Allow deleting loops with assumes.

OK, I think we need to revisit assume but an otherwise empty loop with an assume doesn't seem to be particularly useful. We might want to hoist loop invariant assumes, but that can be revisited. I think this solves a problem and is reasonable until we have time and ideas.

Sep 26 2020, 3:34 AM · Restricted Project
Sep 26 2020, 3:34 AM · Restricted Project

# Sep 12 2020

Reland [AssumeBundles] Use operand bundles to encode alignment assumptions
Tyker updated the diff for D71739: [AssumeBundles] Use operand bundles to encode alignment assumptions.

rebased

Sep 12 2020, 5:35 AM · Restricted Project, Restricted Project
Sep 12 2020, 5:13 AM · Restricted Project, Restricted Project

# Aug 30 2020

[llvm-reduce] Function body reduction: don't forget to unset comdat
Aug 30 2020, 3:18 AM · Restricted Project

# Aug 28 2020

Tyker added a comment to D86816: [LoopDelete][Assume] Allow deleting loops with assumes.

I'd almost say mayHaveSideEffects could have a boolean parameter to ignore droppable uses. Either way, this is right now the best we can do, teach the things that query mayHaveSideEffects and friends about droppable uses. If we have them as flags to all of them that might be easier to do.

Aug 28 2020, 2:56 PM · Restricted Project
Tyker requested review of D86816: [LoopDelete][Assume] Allow deleting loops with assumes.
Aug 28 2020, 2:17 PM · Restricted Project
Tyker committed rG6d3657417e0c: [SROA] Improve handleling of assumes bundles by SROA (authored by Tyker).
[SROA] Improve handleling of assumes bundles by SROA
Aug 28 2020, 12:56 PM · Restricted Project

# Aug 25 2020

Tyker requested review of D86570: [SROA] Improve handleling of assumes bundles by SROA.
Aug 25 2020, 1:06 PM · Restricted Project

# Aug 22 2020

Tyker updated the diff for D86404: [llvm-reduce] Function body reduction: don't forget to unset comdat.

Aug 22 2020, 12:57 PM · Restricted Project

Needs two tests - i agree that comdat makes sense, but i'm not sure about linkage.

Aug 22 2020, 12:08 PM · Restricted Project
Tyker requested review of D86404: [llvm-reduce] Function body reduction: don't forget to unset comdat.
Aug 22 2020, 11:52 AM · Restricted Project
Tyker updated the diff for D82703: [InstCombine] convert assumes to operand bundles.

Aug 22 2020, 11:02 AM · Restricted Project
[llvm-reduce] make llvm-reduce save the best reduction it has when it crashes
Aug 22 2020, 10:17 AM · Restricted Project

# Aug 17 2020

This seems fine to me, thanks.
If you have llvm-reduce crashers, do let me know, i'm interested.

Aug 17 2020, 1:18 PM · Restricted Project
Tyker committed rGa79e604462ea: [AssumeBundles] Fix Bug in Assume Queries (authored by Tyker).
[AssumeBundles] Fix Bug in Assume Queries
Aug 17 2020, 12:37 PM · Restricted Project

# Aug 14 2020

1. I'm pretty sure it's not okay to allocate memory in crash handler.
2. We can't know that the internal state is still consistent.

i agree with both points but all i was trying to do i salvage what can be salvaged.

Aug 14 2020, 3:14 PM · Restricted Project
Tyker updated the diff for D83507: [AssumeBundles] Fix Bug in Assume Queries.

Please rebase and update the affected test :)

Aug 14 2020, 2:19 PM · Restricted Project
Aug 14 2020, 2:08 PM · Restricted Project
Tyker updated the diff for D85144: [clang] Improve Dumping of APValues.

I agree with you that it's fine to use printPretty for leaves (and additionally it would be annoying to duplicate the LValue case); that's what I was planning to do anyway.

What I am not sure I agree with is the additional complexity to handle the (debugger-only and easy to avoid) case where no context is given.

Aug 14 2020, 1:19 PM · Restricted Project
Tyker added a comment to D85933: Don't track consteval references for dependent members.

thanks for this,

Aug 14 2020, 11:43 AM · Restricted Project