In D131468#3708977, @pengfei wrote:D124435 is going to change the assumption :)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Today
Today
Yesterday
Yesterday
yonghong-song added a comment to D131468: [WIP][BPF]: Force sign/zero extension for arguments in callee and return values in caller.
Mon, Aug 8
Mon, Aug 8
yonghong-song retitled D131468: [WIP][BPF]: Force sign/zero extension for arguments in callee and return values in caller from [WIP][BPF]: Force truncation for arguments in callee and return values in caller to [WIP][BPF]: Force sign/zero extension for arguments in callee and return values in caller.
Wed, Jul 13
Wed, Jul 13
yonghong-song committed rG6e6c1efe04d4: [BPF] Handle anon record for CO-RE relocations (authored by yonghong-song).
[BPF] Handle anon record for CO-RE relocations
Jun 29 2022
Jun 29 2022
yonghong-song committed rG70557eb3938a: [clang][BPF] Update comment to include TYPE_MATCH (authored by d-e-s-o).
[clang][BPF] Update comment to include TYPE_MATCH
yonghong-song committed rGd129ac27e872: [BPF] Introduce support for type match relocations (authored by d-e-s-o).
[BPF] Introduce support for type match relocations
Jun 6 2022
Jun 6 2022
yonghong-song committed rGdc1c43d726c8: [BPF] Add BTF 64bit enum value support (authored by yonghong-song).
[BPF] Add BTF 64bit enum value support
Jun 2 2022
Jun 2 2022
In D126839#3554474, @d-e-s-o wrote:In D126839#3554125, @yonghong-song wrote:Also let us merge it unti kernel side change is in reasonable shape.
From what I understand it may take several days or some other not-precisely specified time until "nightly" builds, which we use in the BPF CI, pick up the change. Hence, I was under the impression that we should attempt to merge it sooner rather than later once it's ready to be merged. The kernel changes are in good enough shape to show feasibility, so I don't really see why not, but it's your call.
LGTM. But add the reference (https://reviews.llvm.org/D126838) to the commit message to indicate which 'earlier change'. Also let us merge it unti kernel side change is in reasonable shape.
May 24 2022
May 24 2022
@compnerd provided a better fix https://reviews.llvm.org/D126093, so I am going to close this one.
Sorry. I missed this patch somehow and did another patch https://reviews.llvm.org/D126223. My patch skipped TL.setNameLoc(DS.getTypeSpecTypeNameLoc()); which probably not correct. Accept this patch and abandon my patch D126223.
May 23 2022
May 23 2022
May 20 2022
May 20 2022
@compnerd Thanks for reporting. I will take a look as soon as possible.
May 12 2022
May 12 2022
- also set signed enum for dwarf::DW_ATE_signed_char int.
May 11 2022
May 11 2022
- change kflag meaning: kflag = 0 for unsigned and kflag = 1 for signed.
- change the ordering of enum64 val_lo32 and val_hi32.
May 10 2022
May 10 2022
@Jim Thanks for the updated commit message. Please go ahead to merge to llvm-project main branch if you have write permission. Otherwise, please provide me with peoper git author signature "<name> <email address>" and I can help push the patch for you.
yonghong-song committed rG256a18997e41: [BPF] Add a test for making FI_ri as isPseudo (authored by eddyz87).
[BPF] Add a test for making FI_ri as isPseudo
yonghong-song added a comment to D125185: [BPF] Mark FI_ri as isPseudo to avoid assertion during disassembly.
In D125185#3505000, @ast wrote:a test got lost?
yonghong-song committed rG8a63326150ee: [BPF] Mark FI_ri as isPseudo to avoid assertion during disassembly (authored by eddyz87).
[BPF] Mark FI_ri as isPseudo to avoid assertion during disassembly
yonghong-song added a comment to D125185: [BPF] Mark FI_ri as isPseudo to avoid assertion during disassembly.
Could you provide proper "<Name> <Email Address>" so I can change author to you when I push the commit to the main branch?
The current 'summary' or commit message is too simple. Could you clarify some motivation why you need to add this instruction?
The change itself looks good to me. The kernel selftest test_verifier does test BPF_MOD instruction and I checked verifier code, BPF_MOD is handled similar to BPF_DIV which should be okay in most cases, so I didn't see a major issue here.
The change looks good to me. Do you have write permission to merge into llvm-project main repo? If not, I can do the merge for you.
May 4 2022
May 4 2022
please having proper reviewers. Me, @anakryiko @ast are not the right persons to review this patch.
Apr 28 2022
Apr 28 2022
Apr 27 2022
Apr 27 2022
The BPF doesn't really recommend to compile from the assembly code to the object code, so we should be fine here. But there is a test failure test/CodeGen/BPF/inline_asm.ll. Could you take a look?
Apr 19 2022
Apr 19 2022
yonghong-song committed rG497a5f041594: [BPF] Fix a bug in BPFMISimplifyPatchable pass (authored by klausler).
[BPF] Fix a bug in BPFMISimplifyPatchable pass
yonghong-song committed rG954ba6045dd5: [BPF] Emit fatal error if out of range for FK_PCRel_2 branch target (authored by yonghong-song).
[BPF] Emit fatal error if out of range for FK_PCRel_2 branch target
- create and use isLoadInst() helper function.
yonghong-song updated the diff for D123877: [BPF] Emit fatal error if out of range for FK_PCRel_2 branch target.
- use report_fatal_error instead of assert.
yonghong-song added a comment to D123877: [BPF] Emit fatal error if out of range for FK_PCRel_2 branch target.
In D123877#3459461, @ast wrote:assert is a heavy hammer.
can we exit with report_fatal_error instead?
Apr 18 2022
Apr 18 2022
The UseIntegratedAssembler = false is added with the following commit,
commit d2e5157c1f0b1953c5166c1d656ac71e840615a4 Author: Fangrui Song <i@maskray.me> Date: Sat Apr 11 10:01:36 2020 -0700
Apr 15 2022
Apr 15 2022
Apr 14 2022
Apr 14 2022
yonghong-song committed rG6ee71e53e56b: [BPF] handle opaque-pointer for __builtin_preserve_enum_value (authored by yonghong-song).
[BPF] handle opaque-pointer for __builtin_preserve_enum_value
yonghong-song updated the diff for D123800: [BPF] handle opaque-pointer for __builtin_preserve_enum_value.
- simplify code with stripPointerCasts
yonghong-song added inline comments to D123800: [BPF] handle opaque-pointer for __builtin_preserve_enum_value.
yonghong-song added a comment to D123800: [BPF] handle opaque-pointer for __builtin_preserve_enum_value.
In D123800#3452076, @ast wrote:The fix to prevent the crash looks good, but what should be the expected codegen for a global variable?
CO-RE needs a constant.
Are we assuming that the global data will be inited with some constant and a later pass will propagate it further into __builtin_preserve,
so at the end it will become a constant?
yonghong-song requested review of D123800: [BPF] handle opaque-pointer for __builtin_preserve_enum_value.
Mar 29 2022
Mar 29 2022
yonghong-song committed rG5898979387bc: BPF: support inlining __builtin_memcmp intrinsic call (authored by yonghong-song).
BPF: support inlining __builtin_memcmp intrinsic call
yonghong-song updated the summary of D122676: BPF: support inlining __builtin_memcmp intrinsic call.
Ya, typo. memcpy is okay, it is memcmp. I probably just typing memcpy way more times than memcmp :-) Will change.
Mar 24 2022
Mar 24 2022
yonghong-song accepted D122379: [BPF] Don't fetch alignment of llvm.preserve.union.access.index argument.
Indeed, alignment is not used for union type. Your change looks good to me.
Mar 22 2022
Mar 22 2022
yonghong-song added a comment to D122271: [Clang] -Wunused-but-set-variable warning - handle also pre/post unary operators .
LGTM. Maybe @efriedma can look at this as well.
Mar 21 2022
Mar 21 2022
yonghong-song committed rGbdf69f63df2c: [Clang] Fix an unused-but-set-variable warning with volatile variable (authored by yonghong-song).
[Clang] Fix an unused-but-set-variable warning with volatile variable
Mar 21 2022, 2:59 PM · Restricted Project
yonghong-song updated the diff for D121715: [Clang] Fix an unused-but-set-variable warning with volatile variable.
- fix typo
- add a new test case with typedef of volatile type.
yonghong-song added a comment to D121715: [Clang] Fix an unused-but-set-variable warning with volatile variable.
In D121715#3397407, @efriedma wrote:In D121715#3397215, @xbolva00 wrote:If there is j = j + 1 .. do we warn ?
In D121715#3397237, @xbolva00 wrote:j++;Should not we warn in this case? (Currently no warning)
We probably should warn in both those cases; the variable clearly isn't "used" in any meaningful way.
yonghong-song added inline comments to D121715: [Clang] Fix an unused-but-set-variable warning with volatile variable.
Mar 17 2022
Mar 17 2022
yonghong-song committed rG2e94d8e67a91: [BPF] handle unsigned icmp ops in BPFAdjustOpt pass (authored by yonghong-song).
[BPF] handle unsigned icmp ops in BPFAdjustOpt pass
Mar 17 2022, 4:36 PM · Restricted Project
yonghong-song committed rGd2b4a675a8f9: [BPF] Fix a bug in BPFAdjustOpt pass for icmp transformation (authored by yonghong-song).
[BPF] Fix a bug in BPFAdjustOpt pass for icmp transformation
Mar 17 2022, 9:25 AM · Restricted Project
yonghong-song requested review of D121883: [BPF] Fix a bug in BPFAdjustOpt pass for icmp transformation.
Mar 16 2022
Mar 16 2022
yonghong-song committed rG98e22744580a: [BPF] fix a CO-RE bitfield relocation error with >8 record alignment (authored by yonghong-song).
[BPF] fix a CO-RE bitfield relocation error with >8 record alignment
Mar 16 2022, 12:22 PM · Restricted Project
yonghong-song committed rG212f714ff75e: [lldb] add missed handling for new BTFTagAttributed type (authored by yonghong-song).
[lldb] add missed handling for new BTFTagAttributed type
Mar 16 2022, 11:06 AM · Restricted Project
yonghong-song committed rG3251ba2d0fcf: [Attr] Fix a btf_type_tag AST generation (authored by yonghong-song).
[Attr] Fix a btf_type_tag AST generation
Mar 16 2022, 8:47 AM · Restricted Project
Mar 15 2022
Mar 15 2022
yonghong-song added inline comments to D121715: [Clang] Fix an unused-but-set-variable warning with volatile variable.
yonghong-song updated the diff for D121715: [Clang] Fix an unused-but-set-variable warning with volatile variable.
- only handle volatile variables with component assignment.
- change TransformBTFTagAttributedType() implementation with a simple llvm_unreachable() message. I tested linux kernel and its selftests/bpf compilation with clang and found the only TreeTransformation function is called with TransformAutoType() due to __auto_type usage.
yonghong-song added a comment to D121715: [Clang] Fix an unused-but-set-variable warning with volatile variable.
@eli.friedman Please feel free adding other reviewers if needed. Thanks!
Mar 14 2022
Mar 14 2022
- add one more _Generic test.
Mar 12 2022
Mar 12 2022
- fix one 'auto' declaration issue
- rework on the test with overloadable attribute.
Mar 11 2022
Mar 11 2022
Mar 9 2022
Mar 9 2022
@aaron.ballman @erichkeane Hopefully I addressed your comments. Could you take a look again?
- use BTFTypeTagAttr instead of Attr in PropertiesBase.td
- further clang-format fixes.
- clang-format fix
- change variable names to be llvm compliant.
- remove Attr from BTFTagAttributedTypeLoc as it can be retrieved from the BTFTagAttributedType
- Also transform the attribute in TreeTransform
- add additional test with _Generic and overloadable attribute
@aaron.ballman Thanks for the review! I will address all your comments and will also add tests with _Generic and __attribute__((overloadable)).
Mar 8 2022
Mar 8 2022
- add a pch test to test serialization with btf_type_tag.
- simplify the code
@erichkeane Just posted a patch to address your comments. Could you take a look? I will try to add more tests, esp. serialization and libclang. If you have any suggestions in these two areas (as I am not familiar with them), it would be great!
- address @erichkeane comments
- further TODO: add more tests
Mar 7 2022
Mar 7 2022
@erichkeane Thanks for the review. I will try to address your comments as soon as possible.
Mar 5 2022
Mar 5 2022
@aaron.ballman @erichkeane Just updated the patch with a new implementation, which added a new BTFTagAttributedType instead of reusing existing AttributedType. It is quite complicated and various parts of clang are touched. I mostly just followed what AttributedType did but considering BTFTagAttributedType is C only so my current implementation may unnecessarily complicate things. I didn't have much test coverage either. It would be great you can give a look and let me know (1). what I am missing, (2). where I can simplify things, (3) a different approach if you see fit, (4). what additional tests I should have. Thanks!