Page MenuHomePhabricator

gchatelet (Guillaume Chatelet)
User

Projects

User does not belong to any projects.

User Details

User Since
Jun 7 2017, 7:28 AM (106 w, 6 d)

Recent Activity

Yesterday

gchatelet updated the diff for D63215: Fixing @llvm.memcpy not honoring volatile.
  • Address comments
Mon, Jun 24, 8:33 AM · Restricted Project

Thu, Jun 13

gchatelet updated the diff for D63215: Fixing @llvm.memcpy not honoring volatile.
  • Update argument comments
Thu, Jun 13, 1:52 AM · Restricted Project
gchatelet added a comment to D63215: Fixing @llvm.memcpy not honoring volatile.

What happens if findOptimalMemOpLowering fails? We have other ways of lowering memcpy/memset that could also violate the "one store per byte" rule.

Yes indeed, I need to take care of this as well.

Thu, Jun 13, 1:52 AM · Restricted Project
gchatelet added a comment to D63215: Fixing @llvm.memcpy not honoring volatile.

What happens if findOptimalMemOpLowering fails? We have other ways of lowering memcpy/memset that could also violate the "one store per byte" rule.

Thu, Jun 13, 1:07 AM · Restricted Project

Wed, Jun 12

gchatelet added reviewers for D63215: Fixing @llvm.memcpy not honoring volatile: jfb, t.p.northover, efriedma, regehr.
Wed, Jun 12, 9:10 AM · Restricted Project
gchatelet created D63215: Fixing @llvm.memcpy not honoring volatile.
Wed, Jun 12, 9:04 AM · Restricted Project

Thu, Jun 6

gchatelet updated the diff for D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++.
  • Add documentation.
  • Fix permissive HasNoRuntimeAttribute
  • Mark interleave as disabled in the documentation.
  • Use no-builtin instead of no-runtime-for.
  • Adding an llvm.memcpy.inline intrinsic.
  • Adding __builtin_memcpy_inline clang builtin.
Thu, Jun 6, 9:21 AM · Restricted Project, Restricted Project

May 23 2019

gchatelet updated the diff for D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++.
  • Use no-builtin instead of no-runtime-for.
  • Use one attribute per runtime function to make merging easier.
May 23 2019, 9:20 AM · Restricted Project, Restricted Project
gchatelet accepted D62287: [MergeICmps] Make the pass compatible with the new pass manager..
May 23 2019, 5:30 AM · Restricted Project

May 22 2019

gchatelet added a comment to D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++.

AFAIU here is a coarse plan of what needs to happen

May 22 2019, 7:20 AM · Restricted Project, Restricted Project
gchatelet accepted D62239: [llvm-exegesis] Move native target initialization code to a separate file..
May 22 2019, 6:41 AM · Restricted Project

May 21 2019

gchatelet accepted D62193: [MergeICmps] Make sorting strongly stable on the rhs..
May 21 2019, 7:07 AM · Restricted Project

May 20 2019

gchatelet accepted D62068: [MergeICmps] Preserve the dominator tree..
May 20 2019, 2:31 PM · Restricted Project
gchatelet committed rGe386a01e8459: [NFC] Refactor visitIntrinsicCall so it doesn't return a const char* (authored by gchatelet).
[NFC] Refactor visitIntrinsicCall so it doesn't return a const char*
May 20 2019, 4:00 AM
gchatelet committed rL361140: [NFC] Refactor visitIntrinsicCall so it doesn't return a const char*.
[NFC] Refactor visitIntrinsicCall so it doesn't return a const char*
May 20 2019, 3:59 AM
gchatelet committed rGa760e698405c: Revert "[NFC] Refactor visitIntrinsicCall so it doesn't return a const char*" (authored by gchatelet).
Revert "[NFC] Refactor visitIntrinsicCall so it doesn't return a const char*"
May 20 2019, 2:00 AM
gchatelet committed rL361130: Revert "[NFC] Refactor visitIntrinsicCall so it doesn't return a const char*".
Revert "[NFC] Refactor visitIntrinsicCall so it doesn't return a const char*"
May 20 2019, 2:00 AM
gchatelet committed rGfa8c1525762f: [NFC] Refactor visitIntrinsicCall so it doesn't return a const char* (authored by gchatelet).
[NFC] Refactor visitIntrinsicCall so it doesn't return a const char*
May 20 2019, 1:51 AM
gchatelet committed rL361129: [NFC] Refactor visitIntrinsicCall so it doesn't return a const char*.
[NFC] Refactor visitIntrinsicCall so it doesn't return a const char*
May 20 2019, 1:50 AM
gchatelet closed D61306: [NFC] Refactor visitIntrinsicCall so it doesn't return a const char*.
May 20 2019, 1:49 AM · Restricted Project
gchatelet added a comment to D61306: [NFC] Refactor visitIntrinsicCall so it doesn't return a const char*.

I'll submit this one shortly. @reames please let me know if you have any concerns.

May 20 2019, 1:46 AM · Restricted Project

May 15 2019

gchatelet accepted D61736: [MergeICmps] Simplify the code..
May 15 2019, 5:50 AM · Restricted Project
gchatelet added a comment to D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++.

Using function level attributes instead of module flags does provide finer grained control and avoids the conservativeness when merging IR for LTO. The downsides I see, mostly just in terms of the engineering effort to get this to work, are:

  • need to prevent inlining with different attributes
May 15 2019, 2:57 AM · Restricted Project, Restricted Project

May 14 2019

gchatelet added inline comments to D61736: [MergeICmps] Simplify the code..
May 14 2019, 8:57 AM · Restricted Project
gchatelet updated subscribers of D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++.

My main blocker is that I want to make sure we're moving in the right direction: towards LLVM IR with clear semantics, towards straightforward rules for writing freestanding C code, and towards solutions which behave appropriately for all targets. There's clearly a problem here that's worth solving, but I want to make sure we're adding small features that interact with existing features in an obvious way. The patch as written is adding a new attribute that changes the semantics of C and LLVM IR in a subtle way that interacts with existing optimizations and lowering in ways that are complex and hard to understand.

May 14 2019, 4:42 AM · Restricted Project, Restricted Project

May 13 2019

gchatelet added a comment to D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++.

I still think there are really two things you're trying to accomplish here, which should be handled separately.

  1. Add a function attribute that works like -fno-builtin-memcpy currently does, to prevent the compiler from synthesizing calls to memcpy.
  2. Provide a convenient way to write a small, fixed-length "memcpy", in C and in LLVM IR, that is always expanded to optimal straight-line code (without any calls or loops).

    These correspond to proposals (1) and (2) from your RFC; I think we need both to arrive at a reasonable final state.

    (The "rep; movs" is a third thing, which I think should also be handled separately, but it sounds like you don't think that's very important.)
May 13 2019, 7:18 AM · Restricted Project, Restricted Project
gchatelet added inline comments to D61306: [NFC] Refactor visitIntrinsicCall so it doesn't return a const char*.
May 13 2019, 4:58 AM · Restricted Project
gchatelet accepted D61846: [DAGCombiner] Fix invalid alias analysis..
May 13 2019, 2:02 AM · Restricted Project

May 10 2019

gchatelet added a comment to D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++.

I'm not convinced by the approach.

Can it still recognize the loop idiom into memcpy implementation but use memmove (as only memcpy has been blacklisted)?

May 10 2019, 5:57 AM · Restricted Project, Restricted Project
gchatelet added a comment to D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++.

I would be careful about trying to over-generalize here. There are a few different related bits of functionality which seem to be interesting, given the discussion in the llvm-dev thread, here, and in related patches:

May 10 2019, 5:07 AM · Restricted Project, Restricted Project

May 7 2019

gchatelet added a comment to D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++.

I wonder if a list of comma-separated names is the right approach. Would it make more sense to add a new attribute for each of the helpers, such as #no-runtime-for-memcpy? That should make querying simpler (one lookup in the table, rather than a lookup and a string scan) and also make it easier to add and remove attributes (merging is now just a matter of trying to add all of them, with the existing logic to deduplicate repeated attributes working).

May 7 2019, 8:13 AM · Restricted Project, Restricted Project
gchatelet updated the diff for D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++.
  • Add documentation.
  • Fix permissive HasNoRuntimeAttribute
May 7 2019, 4:42 AM · Restricted Project, Restricted Project
gchatelet updated the summary of D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++.
May 7 2019, 2:49 AM · Restricted Project, Restricted Project
gchatelet created D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++.
May 7 2019, 2:44 AM · Restricted Project, Restricted Project
gchatelet added a reviewer for D61306: [NFC] Refactor visitIntrinsicCall so it doesn't return a const char*: reames.
May 7 2019, 1:39 AM · Restricted Project
gchatelet added inline comments to D61306: [NFC] Refactor visitIntrinsicCall so it doesn't return a const char*.
May 7 2019, 1:39 AM · Restricted Project

May 6 2019

gchatelet committed rGedd69fca3ea5: Modernize repmovsb implementation of x86 memcpy and allow runtime sizes. (authored by gchatelet).
Modernize repmovsb implementation of x86 memcpy and allow runtime sizes.
May 6 2019, 8:08 AM
gchatelet committed rL360050: Modernize repmovsb implementation of x86 memcpy and allow runtime sizes..
Modernize repmovsb implementation of x86 memcpy and allow runtime sizes.
May 6 2019, 8:08 AM
gchatelet closed D61593: [NFC] Modernize repmovsb implementation of x86 memcpy..
May 6 2019, 8:08 AM · Restricted Project
gchatelet updated the diff for D61593: [NFC] Modernize repmovsb implementation of x86 memcpy..
  • Addressing comments
May 6 2019, 8:00 AM · Restricted Project
gchatelet updated the diff for D61593: [NFC] Modernize repmovsb implementation of x86 memcpy..
  • Addressing comments
May 6 2019, 8:00 AM · Restricted Project
gchatelet retitled D61593: [NFC] Modernize repmovsb implementation of x86 memcpy. from Modernize repmovsb implementation of x86 memcpy and allow runtime sizes. to [NFC] Modernize repmovsb implementation of x86 memcpy..
May 6 2019, 7:19 AM · Restricted Project
gchatelet updated the diff for D61593: [NFC] Modernize repmovsb implementation of x86 memcpy..
  • Turn this patch into an NFC.
May 6 2019, 7:19 AM · Restricted Project
gchatelet updated the diff for D61593: [NFC] Modernize repmovsb implementation of x86 memcpy..
  • Fix typo.
May 6 2019, 6:39 AM · Restricted Project
gchatelet updated the diff for D61306: [NFC] Refactor visitIntrinsicCall so it doesn't return a const char*.
  • clang-format
May 6 2019, 6:37 AM · Restricted Project
gchatelet created D61593: [NFC] Modernize repmovsb implementation of x86 memcpy..
May 6 2019, 6:32 AM · Restricted Project
gchatelet committed rG3cfb48b87729: [NFC] Update memcpy tests (authored by gchatelet).
[NFC] Update memcpy tests
May 6 2019, 2:47 AM
gchatelet committed rL360023: [NFC] Update memcpy tests.
[NFC] Update memcpy tests
May 6 2019, 2:47 AM
gchatelet closed D61507: [NFC] Update memcpy tests.
May 6 2019, 2:47 AM · Restricted Project
gchatelet added a comment to D61507: [NFC] Update memcpy tests.

Thx for the review @lebedev.ri !

May 6 2019, 2:07 AM · Restricted Project
gchatelet updated the diff for D61507: [NFC] Update memcpy tests.
  • Remove cfi noise by adding nounwind
May 6 2019, 2:07 AM · Restricted Project
gchatelet accepted D61585: [SimplifyLibCalls] Simplify bcmp too..
May 6 2019, 1:59 AM · Restricted Project

May 3 2019

gchatelet created D61507: [NFC] Update memcpy tests.
May 3 2019, 7:08 AM · Restricted Project

Apr 30 2019

gchatelet updated the diff for D61306: [NFC] Refactor visitIntrinsicCall so it doesn't return a const char*.
  • Update documentation
Apr 30 2019, 6:38 AM · Restricted Project
gchatelet added a reviewer for D61306: [NFC] Refactor visitIntrinsicCall so it doesn't return a const char*: sanjoy.
Apr 30 2019, 6:36 AM · Restricted Project
gchatelet updated the diff for D61306: [NFC] Refactor visitIntrinsicCall so it doesn't return a const char*.
  • Fix typo
Apr 30 2019, 6:21 AM · Restricted Project
gchatelet created D61306: [NFC] Refactor visitIntrinsicCall so it doesn't return a const char*.
Apr 30 2019, 6:21 AM · Restricted Project

Apr 26 2019

gchatelet abandoned D60719: Demonstrate how to fix freestanding for memcpy.
Apr 26 2019, 5:44 AM · Restricted Project, Restricted Project

Apr 18 2019

gchatelet added a comment to D60719: Demonstrate how to fix freestanding for memcpy.

IIUC freestanding environment should not rely on memcpy being present so my take on it was that by "fixing" freestanding I could have my cake and eat it too.

The formal situation is that freestanding implementations are only required to provide language support stuff like va_list. They're allowed to give more of the standard library if they want though, as implementation defined behaviour.

In practice, everyone I know provides the basic string.h functions and the compiler is pretty explicit about relying on them being present for correctness. They're part of the surrounding environment a user is expected to supply (much like the various exception handling callbacks if you want C++ exceptions, but always required).

For the people actually using freestanding I think they're mostly considered important enough that they're implemented in assembly anyway so this isn't really a burden, but...

Apr 18 2019, 1:46 AM · Restricted Project, Restricted Project

Apr 17 2019

gchatelet added a comment to D60719: Demonstrate how to fix freestanding for memcpy.

I think it'd be pretty unpopular with the people I know who use freestanding. They're mostly working on microcontrollers and compiling -Oz so the extra code size would be untenable; they also have memcpy implementations anyway because they use it in their own code.

If I was trying to solve this (and I'm also not 100% sure it needs solving), I think I'd instead generate a linkonce definition of memcpy whenever it's needed and leave CodeGen unmodified.

Apr 17 2019, 5:57 AM · Restricted Project, Restricted Project

Apr 16 2019

gchatelet updated the diff for D60719: Demonstrate how to fix freestanding for memcpy.

Add test.

Apr 16 2019, 6:47 AM · Restricted Project, Restricted Project

Apr 15 2019

gchatelet retitled D60719: Demonstrate how to fix freestanding for memcpy from Fixing freestanding for memcpy. to Demonstrate how to fix freestanding for memcpy.
Apr 15 2019, 9:48 AM · Restricted Project, Restricted Project
gchatelet created D60719: Demonstrate how to fix freestanding for memcpy.
Apr 15 2019, 9:47 AM · Restricted Project, Restricted Project

Apr 11 2019

gchatelet added a comment to D60401: [llvm-exegesis] When generating templates with chained instructions, also add templates for helper instructions.

...

So i agree in general, but i don't think i agree with fine print.

What if i don't want to validate the whole entirety of the instructions,
but only one of these instructions that is Measurable through another instruction?
I simply can't?

Apr 11 2019, 5:20 AM · Restricted Project
gchatelet added a comment to D60401: [llvm-exegesis] When generating templates with chained instructions, also add templates for helper instructions.

I understand the motivation behind this change but I think we need a more principled approach. I'll try to sum up my reasoning here.
To me there are two useful modes for llvm-exegesis:

  • We want to look at a particular instruction latency - useful when we want to quickly check an assumption,
  • We want to get the latency for all the instructions - useful to fully characterize or check a processor.
Apr 11 2019, 4:31 AM · Restricted Project

Apr 8 2019

gchatelet accepted D60066: [llvm-exegesis][X86] Randomize CMOVcc/SETcc OPERAND_COND_CODE CondCodes.
Apr 8 2019, 2:54 AM · Restricted Project

Apr 5 2019

gchatelet committed rG848df5b50903: Add an option do not dump the generated object on disk (authored by gchatelet).
Add an option do not dump the generated object on disk
Apr 5 2019, 8:20 AM
gchatelet committed rL357769: Add an option do not dump the generated object on disk.
Add an option do not dump the generated object on disk
Apr 5 2019, 8:17 AM
gchatelet closed D60317: Add an option do not dump the generated object on disk.
Apr 5 2019, 8:17 AM · Restricted Project
gchatelet updated the diff for D60317: Add an option do not dump the generated object on disk.
  • Move comment to the right line.
Apr 5 2019, 8:07 AM · Restricted Project
gchatelet created D60317: Add an option do not dump the generated object on disk.
Apr 5 2019, 7:58 AM · Restricted Project

Apr 4 2019

gchatelet added a comment to D60000: [llvm-exegesis] Post-processing for chained instrs in latency mode (PR41275).

Intermediate issue to solve: creating all these 2-instr chained configs must then also
create configs to measure the params of that second instr (without going into endless loop).

Apr 4 2019, 3:36 AM · Restricted Project

Apr 3 2019

gchatelet added a comment to D60000: [llvm-exegesis] Post-processing for chained instrs in latency mode (PR41275).

To me, a better approach would be to read all the experiments, create the dependency graph between the 2-instructions snippets and solve a system of equations to recover the per instruction latency, then use the analyzer on the result.

Can you explain that in a bit more detail? Something like

lat(i_0) = m_0
sum(lat(i_t)+lat(i_0)) = m_1
lat(i_1) = m_2
sum(lat(i_t)+lat(i_1)) = m_3
...
lat(i_n) => ?
sum(lat(i_t)+lat(i_n)) = m_n
lat(i_t) => ?

Do you suggest to take known lat(i_0)..lat(i_n) from measurements too?

Apr 3 2019, 4:28 AM · Restricted Project

Apr 2 2019

gchatelet accepted D60057: [llvm-exegesis] Handle CMOV's OPERAND_COND_CODE OperandType.
Apr 2 2019, 6:22 AM · Restricted Project
gchatelet added a comment to D60000: [llvm-exegesis] Post-processing for chained instrs in latency mode (PR41275).

It doesn't feel like the right approach to me.
llvm-exegesis is about relying on measurement to deduce informations. Here you're using a priori knowledge (SchedClass) which may be wrong.
To me, a better approach would be to read all the experiments, create the dependency graph between the 2-instructions snippets and solve a system of equations to recover the per instruction latency, then use the analyzer on the result.

Apr 2 2019, 6:08 AM · Restricted Project

Mar 27 2019

gchatelet added a comment to D59821: [llvm-exegesis] Allow the target to disable the selection of some registers..

What protects R8-R15 in 32-bit mode or SIL/DIL/BPL/SPL?

Mar 27 2019, 1:20 AM · Restricted Project

Mar 26 2019

gchatelet accepted D59821: [llvm-exegesis] Allow the target to disable the selection of some registers..

Thx!

Mar 26 2019, 7:52 AM · Restricted Project

Mar 22 2019

gchatelet accepted D59693: [llvm-exegesis] Add clustering test..
Mar 22 2019, 6:08 AM · Restricted Project

Mar 20 2019

gchatelet accepted D59593: [ExpandMemCmp] Trigger on bcmp too..
Mar 20 2019, 3:26 AM · Restricted Project

Feb 25 2019

gchatelet accepted D58285: [llvm-exegesis] Teach llvm-exegesis to handle instructions with multiple tied variables..
Feb 25 2019, 1:27 AM · Restricted Project

Feb 18 2019

gchatelet committed rGbd604e011f04: [llvm-exegesis] [NFC] Fixing typo. (authored by gchatelet).
[llvm-exegesis] [NFC] Fixing typo.
Feb 18 2019, 2:09 AM
gchatelet committed rL354250: [llvm-exegesis] [NFC] Fixing typo..
[llvm-exegesis] [NFC] Fixing typo.
Feb 18 2019, 2:08 AM
gchatelet closed D54895: [llvm-exegesis] [NFC] Fixing typo..
Feb 18 2019, 2:08 AM · Restricted Project

Feb 15 2019

gchatelet accepted D58274: [MergeICmps] Make base ordering really deterministic..
Feb 15 2019, 5:05 AM · Restricted Project
gchatelet added inline comments to D58274: [MergeICmps] Make base ordering really deterministic..
Feb 15 2019, 2:11 AM · Restricted Project

Feb 12 2019

gchatelet added a comment to D56593: [SelectionDAG][RFC] Allow the user to specify a memeq function (v5)..

It'd be great to see this somewhat more widely publicized, outside of just the clang community. If libc implementors are aware of the gains and are willing to provide an actually-faster bcmp implementation, it'd be a lot better, than having this optimization that doesn't really optimize anything without users providing their own bcmp implementation.

Feb 12 2019, 1:35 AM · Restricted Project

Feb 6 2019

gchatelet added a comment to D57699: [yaml::BinaryRef] Slight perf tuning (for llvm-exegesis analysis mode).

I think i'm gonna land this.
It's semantically correct, has better perf characteristics, is a very small change, and is symmetrical with writeAsHex().

Feb 6 2019, 12:52 AM · Restricted Project

Feb 5 2019

gchatelet added inline comments to D56593: [SelectionDAG][RFC] Allow the user to specify a memeq function (v5)..
Feb 5 2019, 1:51 AM · Restricted Project

Feb 4 2019

gchatelet accepted D57699: [yaml::BinaryRef] Slight perf tuning (for llvm-exegesis analysis mode).

Thx for working on this Roman. I'm not the one who designed the YAML IO library so perhaps the author is a better reviewer.
LGTM AFAIC

Feb 4 2019, 9:00 PM · Restricted Project

Jan 21 2019

gchatelet accepted D57000: [llvm-exegesis] Add throughput mode..
Jan 21 2019, 11:51 PM

Nov 26 2018

gchatelet committed rCTE347570: [clang-tidy] Improving narrowing conversions.
[clang-tidy] Improving narrowing conversions
Nov 26 2018, 8:29 AM
gchatelet committed rL347570: [clang-tidy] Improving narrowing conversions.
[clang-tidy] Improving narrowing conversions
Nov 26 2018, 8:28 AM
gchatelet closed D53488: [clang-tidy] Improving narrowing conversions.
Nov 26 2018, 8:28 AM · Restricted Project
gchatelet accepted D54895: [llvm-exegesis] [NFC] Fixing typo..
Nov 26 2018, 6:26 AM · Restricted Project
gchatelet added a comment to D53488: [clang-tidy] Improving narrowing conversions.

LGTM!

Nov 26 2018, 5:38 AM · Restricted Project
gchatelet updated the diff for D53488: [clang-tidy] Improving narrowing conversions.
  • Removed redundant options in regression tests
Nov 26 2018, 5:22 AM · Restricted Project
gchatelet updated the diff for D53488: [clang-tidy] Improving narrowing conversions.
  • Fixing documentation.
Nov 26 2018, 1:21 AM · Restricted Project
gchatelet added a comment to D53488: [clang-tidy] Improving narrowing conversions.

Thank you for bearing with me @aaron.ballman.

Nov 26 2018, 1:06 AM · Restricted Project
gchatelet updated the diff for D53488: [clang-tidy] Improving narrowing conversions.
  • Addressing comments
Nov 26 2018, 1:06 AM · Restricted Project

Nov 23 2018

gchatelet added inline comments to D53488: [clang-tidy] Improving narrowing conversions.
Nov 23 2018, 1:15 PM · Restricted Project