Page MenuHomePhabricator

nlguillemot (Nicolas Guillemot)
User

Projects

User does not belong to any projects.

User Details

User Since
Jun 11 2019, 10:24 AM (66 w, 6 d)

Recent Activity

Aug 14 2020

nlguillemot committed rG3cf7efec986d: [TableGen] Allow mnemonics with uppercase letters to be matched (authored by nlguillemot).
[TableGen] Allow mnemonics with uppercase letters to be matched
Aug 14 2020, 2:48 PM
nlguillemot closed D85858: [TableGen] Allow mnemonics with uppercase letters to be matched.
Aug 14 2020, 2:48 PM · Restricted Project

Aug 12 2020

nlguillemot requested review of D85858: [TableGen] Allow mnemonics with uppercase letters to be matched.
Aug 12 2020, 3:43 PM · Restricted Project

May 8 2020

nlguillemot added a comment to D78796: [Support] Refactor LEB128 encoding into an input iterator.

Thanks for the comments. Added some replies.

May 8 2020, 11:47 AM · Restricted Project

May 7 2020

nlguillemot added a comment to D78796: [Support] Refactor LEB128 encoding into an input iterator.

I'm inclined to agree that the patch series as-is doesn't really warrant the iterators as the interface as no callers have been updated. However, I also don't see much that's iterator specific (ULEBifier would be roughly similar code leaving the iterator portion as trivial wrappers on the ULEBifier) and there are a few places (particularly in tablegen) that are emitting LEB's into containers where the loop to add bytes one by one is just noise and something like std::copy(to_uleb(...), std::back_inserter(Table)); would be somewhat nice. The loop could easily be hidden in something like append_uleb(Table, ...) though I don't think there's a strong argument for (or against) iterators.

What I would suggest is separating out the byte-sequence generation into a ULEBifier as David suggested but still keeping the iterator object as a thin adapter (effectively implementing that while loop) to support inter-operation with STL functions like std::copy.

What is the core issue with the iterator interface that makes it desirable to have something like ULEBifier<T> instead?

For me it's that iterators reference and indirect into the elements of a container. They shouldn't be the container themselves

May 7 2020, 2:41 PM · Restricted Project
nlguillemot added a comment to D78796: [Support] Refactor LEB128 encoding into an input iterator.

I'm inclined to agree that the patch series as-is doesn't really warrant the iterators as the interface as no callers have been updated. However, I also don't see much that's iterator specific (ULEBifier would be roughly similar code leaving the iterator portion as trivial wrappers on the ULEBifier) and there are a few places (particularly in tablegen) that are emitting LEB's into containers where the loop to add bytes one by one is just noise and something like std::copy(to_uleb(...), std::back_inserter(Table)); would be somewhat nice. The loop could easily be hidden in something like append_uleb(Table, ...) though I don't think there's a strong argument for (or against) iterators.

What I would suggest is separating out the byte-sequence generation into a ULEBifier as David suggested but still keeping the iterator object as a thin adapter (effectively implementing that while loop) to support inter-operation with STL functions like std::copy.

May 7 2020, 1:02 PM · Restricted Project
nlguillemot added inline comments to D78795: [Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream..
May 7 2020, 10:14 AM · Restricted Project

Apr 28 2020

nlguillemot added a comment to D78796: [Support] Refactor LEB128 encoding into an input iterator.

I'm not sure this is worth a full iterator abstraction - would the uses be that much the worse for it if they had a non-iterator type they had to iterate manually & pull values from? A more simplified iterator abstraction, essentially:

ULEBifier U(Value, IsSigned, PadTo);
while (Optional<char> C = U.next())
  OS.write(*C);

Or something like that.

Apr 28 2020, 12:23 PM · Restricted Project
nlguillemot added a comment to D78795: [Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream..

Thanks for the review @dblaikie !

Apr 28 2020, 10:44 AM · Restricted Project
nlguillemot added a comment to D78795: [Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream..

Maybe hold of on committing this until some of the rest of the patch sequence has been reviewed/approved, in case it doesn't end up being needed.

Apr 28 2020, 10:44 AM · Restricted Project
nlguillemot updated the diff for D78795: [Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream..
  • Added some basic tests that use raw_ostream_iterator manually instead of through std::copy.
  • Replaced manual calls to flush() in the test with an artificial scope (takes advantage of the fact that ~raw_string_ostream() calls flush())
  • Added a test for std::copy with an empty range.
Apr 28 2020, 10:44 AM · Restricted Project

Apr 27 2020

nlguillemot created D78964: [Support] Handle signed padding in decodeLEB128 + add multi-sized tests.
Apr 27 2020, 1:31 PM · Restricted Project

Apr 26 2020

nlguillemot abandoned D63374: [TableGen] Add "MCInstValidatorEmitter" TableGen backend.

Abandoning this project.

Apr 26 2020, 4:28 PM
nlguillemot added a reviewer for D78797: [Support] Refactor LEB128 decoding into an output iterator: rtereshin.
Apr 26 2020, 11:40 AM · Restricted Project
nlguillemot added a reviewer for D78857: [Support] Generalize operations on ValueT for LEB128 encoding/decoding: rtereshin.
Apr 26 2020, 11:40 AM · Restricted Project
nlguillemot added a reviewer for D78858: [Support] Add APInt support for LEB128 encoding/decoding: rtereshin.
Apr 26 2020, 11:40 AM · Restricted Project
nlguillemot added a reviewer for D78795: [Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream.: rtereshin.
Apr 26 2020, 11:40 AM · Restricted Project
nlguillemot added a reviewer for D78796: [Support] Refactor LEB128 encoding into an input iterator: rtereshin.
Apr 26 2020, 11:40 AM · Restricted Project

Apr 24 2020

nlguillemot created D78858: [Support] Add APInt support for LEB128 encoding/decoding.
Apr 24 2020, 11:25 PM · Restricted Project
nlguillemot created D78857: [Support] Generalize operations on ValueT for LEB128 encoding/decoding.
Apr 24 2020, 11:25 PM · Restricted Project
nlguillemot updated the diff for D78797: [Support] Refactor LEB128 decoding into an output iterator.

Replaced assignments of 0 with assignments of ValueT(), as a more generic way to get a zero value.

Apr 24 2020, 11:15 PM · Restricted Project
nlguillemot updated the diff for D78796: [Support] Refactor LEB128 encoding into an input iterator.

Updated comments about zext to include a mention of sext.

Apr 24 2020, 11:12 PM · Restricted Project
nlguillemot added inline comments to D78796: [Support] Refactor LEB128 encoding into an input iterator.
Apr 24 2020, 9:05 PM · Restricted Project
nlguillemot updated the diff for D78797: [Support] Refactor LEB128 decoding into an output iterator.

Rebased this patch on top of its parent commit.

Apr 24 2020, 2:05 PM · Restricted Project
nlguillemot updated the diff for D78796: [Support] Refactor LEB128 encoding into an input iterator.

Removed unnecessary inline

Apr 24 2020, 2:05 PM · Restricted Project
nlguillemot updated the diff for D78796: [Support] Refactor LEB128 encoding into an input iterator.

Refactored the encode functions more aggressively by factoring out the common logic for writing to an array or to a raw_ostream:

diff
diff --git a/llvm/include/llvm/Support/LEB128.h b/llvm/include/llvm/Support/LEB128.h
index 729ee5ca745..f65dc919e39 100644
--- a/llvm/include/llvm/Support/LEB128.h
+++ b/llvm/include/llvm/Support/LEB128.h
@@ -168,43 +168,52 @@ public:
   ///@}
 };
Apr 24 2020, 2:05 PM · Restricted Project
nlguillemot updated the diff for D78797: [Support] Refactor LEB128 decoding into an output iterator.

Added a unit test that uses the output iterator in a std algorithm, just as a sanity test that the class can indeed be used as an output iterator. The code in decode[U|S]LEB128 doesn't use the output iterator with std algorithm, so this extra test was added to get coverage for that use case.

Apr 24 2020, 10:48 AM · Restricted Project

Apr 23 2020

nlguillemot updated the diff for D78797: [Support] Refactor LEB128 decoding into an output iterator.

Forgot to include a few changes in the original diff that was posted.

Apr 23 2020, 11:57 PM · Restricted Project
nlguillemot added a comment to D78797: [Support] Refactor LEB128 decoding into an output iterator.

The end goal of this series of patches is to support encoding/decoding APInt to/from [U|S]LEB128. This patch is an initial step in that direction. It refactors the logic to avoid code duplication and makes the interface to LEB128 decoding more generic.

Apr 23 2020, 11:57 PM · Restricted Project
nlguillemot added a comment to D78795: [Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream..

This is patch is mainly useful for enabling some of the refactors that happen in the next patch here: https://reviews.llvm.org/D78796

Apr 23 2020, 11:57 PM · Restricted Project
nlguillemot added a comment to D78796: [Support] Refactor LEB128 encoding into an input iterator.

The end goal of this series of patches is to support encoding/decoding APInt to/from [U|S]LEB128. This patch is an initial step in that direction. It refactors the logic to avoid code duplication and makes the interface to LEB128 encoding much more generic, as shown by the existing cases becoming very short.

Apr 23 2020, 11:57 PM · Restricted Project
nlguillemot updated the summary of D78795: [Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream..
Apr 23 2020, 11:57 PM · Restricted Project
nlguillemot updated the diff for D78795: [Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream..

Some example code and the commit message were showing an example of printing a vector<double>. It turns out that doubles don't print so beautifully by default, so switch the example to use int instead to avoid being misleading.

Apr 23 2020, 11:57 PM · Restricted Project
nlguillemot created D78796: [Support] Refactor LEB128 encoding into an input iterator.
Apr 23 2020, 11:57 PM · Restricted Project
nlguillemot created D78797: [Support] Refactor LEB128 decoding into an output iterator.
Apr 23 2020, 11:57 PM · Restricted Project
nlguillemot created D78795: [Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream..
Apr 23 2020, 11:25 PM · Restricted Project

Jan 6 2020

nlguillemot added a comment to D68054: Regex: Add static convenience functions for "match" and "sub".

How about the following commit message:

(...)

Jan 6 2020, 9:27 AM · Restricted Project

Nov 21 2019

nlguillemot added a comment to D68054: Regex: Add static convenience functions for "match" and "sub".

Not committing to remove the ability to call match/sub on an invalid regex implies that the addition of the new API needs to be justified independently of the extra check that needs to be performed in match/sub to allow the current behaviour. And in fact, the only motivation for this patch I could think of was consistency with other languages and I was finding it a hard sell and was about to apologise for the extra work I made you do.

However I overlooked one benefit of removing the ability to match an invalid regex: robustness. All the cases where a call to match/sub is guards a code other than throwing an error is likely to result in wrong behaviour in case the regex is invalid. So I think it would be safer to use a separate API for combined regex creation + match/sub as per the previous revision of this patch and prevent the existing approach, so that users are mindful when not doing separate checks.

What do you think? If you agree that would mean reverting to the previous version of this patch and the simultaneous apologies from me for requesting the current version.

Nov 21 2019, 9:25 AM · Restricted Project

Nov 19 2019

nlguillemot added a comment to D68155: [clang][NFC] Make various uses of Regex const.

My sincere apologies, I forgot to change the author in the commit. I don't often commit on behalf of others so didn't think enough.

Nov 19 2019, 10:06 AM · Restricted Project
nlguillemot updated the summary of D68054: Regex: Add static convenience functions for "match" and "sub".
Nov 19 2019, 10:06 AM · Restricted Project
nlguillemot added a comment to D68054: Regex: Add static convenience functions for "match" and "sub".

Removed the assert inside match() that made it crash when match() is called with a regex pattern that isn't successfully compiled. Also removed the "death test" unit tests that tested that this assert was triggering.

Can you reword the description along the line of this new API being a convenience when one does not care about distinguishing validity of a regex from whether it matches?

Nov 19 2019, 10:06 AM · Restricted Project

Nov 18 2019

nlguillemot updated the diff for D68054: Regex: Add static convenience functions for "match" and "sub".

Removed the assert inside match() that made it crash when match() is called with a regex pattern that isn't successfully compiled. Also removed the "death test" unit tests that tested that this assert was triggering.

Nov 18 2019, 4:11 PM · Restricted Project

Sep 27 2019

nlguillemot added a comment to D68054: Regex: Add static convenience functions for "match" and "sub".

Opened a review that just increases the const-correctness of Regex in clang: https://reviews.llvm.org/D68155

Sep 27 2019, 12:17 PM · Restricted Project
nlguillemot created D68155: [clang][NFC] Make various uses of Regex const.
Sep 27 2019, 12:17 PM · Restricted Project
nlguillemot added a comment to D68054: Regex: Add static convenience functions for "match" and "sub".

The following clang unit tests fail with your patch:

Format/./FormatTests/FormatTest.FunctionAnnotations
Format/./FormatTests/FormatTest.UnderstandsFunctionRefQualification

Can you have a look?

Sep 27 2019, 11:09 AM · Restricted Project

Sep 26 2019

nlguillemot added inline comments to D68054: Regex: Add static convenience functions for "match" and "sub".
Sep 26 2019, 10:35 AM · Restricted Project
nlguillemot created D68091: [sancov][NFC] Make filename Regexes "const".
Sep 26 2019, 10:35 AM · Restricted Project
nlguillemot added inline comments to D68054: Regex: Add static convenience functions for "match" and "sub".
Sep 26 2019, 10:15 AM · Restricted Project
nlguillemot updated the diff for D68054: Regex: Add static convenience functions for "match" and "sub".
  • Added more comments to static match and static sub to clarify the return value and the error's value.
  • Remove updates of "static Regex" -> "static const Regex", to do them in a future separate patch instead.
  • Switch order of test lines in "ConvenienceFunctions" test.
Sep 26 2019, 10:15 AM · Restricted Project

Sep 25 2019

nlguillemot added inline comments to D68054: Regex: Add static convenience functions for "match" and "sub".
Sep 25 2019, 2:50 PM · Restricted Project
nlguillemot created D68054: Regex: Add static convenience functions for "match" and "sub".
Sep 25 2019, 2:41 PM · Restricted Project

Sep 23 2019

nlguillemot added a comment to D67241: Regex: Make "match" and "sub" const member functions.

friendly reminder ping

My bad, I misunderstood you and thought you'd do a patch to implement the "Create a Regex and immediately throw it away" idiom and rebase that one on top of it.

Sep 23 2019, 4:07 PM · Restricted Project
nlguillemot added a comment to D67241: Regex: Make "match" and "sub" const member functions.

friendly reminder ping

Sep 23 2019, 9:22 AM · Restricted Project

Sep 18 2019

nlguillemot updated the diff for D66773: [TableGen] Emit OperandType enums for RegisterOperands/RegisterClasses.

Refactored loop over the list of vectors to avoid the tricky array/pointer loops.

Sep 18 2019, 1:51 PM · Restricted Project
nlguillemot added inline comments to D66773: [TableGen] Emit OperandType enums for RegisterOperands/RegisterClasses.
Sep 18 2019, 1:01 PM · Restricted Project
nlguillemot added a reviewer for D66773: [TableGen] Emit OperandType enums for RegisterOperands/RegisterClasses: bogner.
Sep 18 2019, 11:40 AM · Restricted Project
nlguillemot added a reviewer for D66773: [TableGen] Emit OperandType enums for RegisterOperands/RegisterClasses: dsanders.
Sep 18 2019, 10:17 AM · Restricted Project

Sep 11 2019

nlguillemot added a reviewer for D67241: Regex: Make "match" and "sub" const member functions: thopre.
Sep 11 2019, 9:15 AM · Restricted Project

Sep 10 2019

nlguillemot added inline comments to D67241: Regex: Make "match" and "sub" const member functions.
Sep 10 2019, 1:30 PM · Restricted Project

Sep 6 2019

nlguillemot added inline comments to D67241: Regex: Make "match" and "sub" const member functions.
Sep 6 2019, 2:50 PM · Restricted Project
nlguillemot updated the diff for D67241: Regex: Make "match" and "sub" const member functions.

Added note in the comments for match and sub to explicitly note that the Error string is cleared when there is no error.

Sep 6 2019, 9:49 AM · Restricted Project
nlguillemot added inline comments to D67241: Regex: Make "match" and "sub" const member functions.
Sep 6 2019, 9:42 AM · Restricted Project

Sep 5 2019

nlguillemot created D67241: Regex: Make "match" and "sub" const member functions.
Sep 5 2019, 2:59 PM · Restricted Project

Aug 26 2019

nlguillemot added a reviewer for D66773: [TableGen] Emit OperandType enums for RegisterOperands/RegisterClasses: ab.
Aug 26 2019, 4:22 PM · Restricted Project
nlguillemot created D66773: [TableGen] Emit OperandType enums for RegisterOperands/RegisterClasses.
Aug 26 2019, 4:19 PM · Restricted Project

Aug 16 2019

nlguillemot created D66369: [TableGen] Make MCInst decoding more table-driven.
Aug 16 2019, 4:03 PM · Restricted Project

Aug 9 2019

nlguillemot updated the summary of D63741: [TableGen] Add "InitValue": Handle operands with set bit values in decoder methods.
Aug 9 2019, 10:27 AM · Restricted Project
nlguillemot added a comment to D63741: [TableGen] Add "InitValue": Handle operands with set bit values in decoder methods.

I don't have commit privileges yet. Could somebody commit this for me?

Aug 9 2019, 9:06 AM · Restricted Project

Aug 1 2019

nlguillemot added inline comments to D63741: [TableGen] Add "InitValue": Handle operands with set bit values in decoder methods.
Aug 1 2019, 1:18 PM · Restricted Project

Jul 19 2019

nlguillemot added inline comments to D63741: [TableGen] Add "InitValue": Handle operands with set bit values in decoder methods.
Jul 19 2019, 9:11 AM · Restricted Project

Jul 18 2019

nlguillemot added inline comments to D63374: [TableGen] Add "MCInstValidatorEmitter" TableGen backend.
Jul 18 2019, 10:15 AM

Jul 16 2019

nlguillemot added a comment to D63320: [TableGen] Add "getOperandType" to get operand types from opcode/opidx.

Could somebody do the commit for me? I don’t have commit access yet.

Jul 16 2019, 2:44 PM · Restricted Project

Jul 9 2019

nlguillemot added a comment to D63741: [TableGen] Add "InitValue": Handle operands with set bit values in decoder methods.

ping

Jul 9 2019, 9:12 AM · Restricted Project
nlguillemot added a comment to D63374: [TableGen] Add "MCInstValidatorEmitter" TableGen backend.

ping

Jul 9 2019, 9:12 AM
nlguillemot added a comment to D63320: [TableGen] Add "getOperandType" to get operand types from opcode/opidx.

ping

Jul 9 2019, 9:12 AM · Restricted Project

Jun 25 2019

nlguillemot added a reviewer for D63741: [TableGen] Add "InitValue": Handle operands with set bit values in decoder methods: fhahn.
Jun 25 2019, 11:01 AM · Restricted Project

Jun 24 2019

nlguillemot created D63741: [TableGen] Add "InitValue": Handle operands with set bit values in decoder methods.
Jun 24 2019, 3:14 PM · Restricted Project

Jun 18 2019

nlguillemot added a comment to D63320: [TableGen] Add "getOperandType" to get operand types from opcode/opidx.

Can the enum be used without this? I'm trying to understand why the enum was there to begin with. Only one in tree target, AVR, defines GET_INSTRINFO_OPERAND_TYPES_ENUM. Its not built by default so I could't really check, but looking through the file that included it, I couldn't prove it was being used.

Jun 18 2019, 3:38 PM · Restricted Project
nlguillemot updated the diff for D63320: [TableGen] Add "getOperandType" to get operand types from opcode/opidx.

some syntax nits:
OpcodeOperandTypes [] -> OpcodeOperandTypes[] (removed unnecessary space)
OS << "-1"; -> OS << -1; (don't use string where not necessary

Jun 18 2019, 2:20 PM · Restricted Project

Jun 15 2019

nlguillemot created D63374: [TableGen] Add "MCInstValidatorEmitter" TableGen backend.
Jun 15 2019, 1:19 AM

Jun 14 2019

nlguillemot updated the diff for D63320: [TableGen] Add "getOperandType" to get operand types from opcode/opidx.
  • Fix some syntax mistakes.
  • Map only records that derive from Operand and are not anonymous. This exactly matches the condition used to generate GET_INSTRINFO_OPERAND_TYPES_ENUM.
Jun 14 2019, 10:04 AM · Restricted Project
nlguillemot added a reviewer for D63320: [TableGen] Add "getOperandType" to get operand types from opcode/opidx: ab.
Jun 14 2019, 9:06 AM · Restricted Project
nlguillemot created D63320: [TableGen] Add "getOperandType" to get operand types from opcode/opidx.
Jun 14 2019, 12:50 AM · Restricted Project

Jun 11 2019

Herald added a project to D52369: [tblgen][disasm] Allow multiple encodings to disassemble to the same instruction: Restricted Project.
Jun 11 2019, 11:15 AM · Restricted Project