For every instruction, it's documented whether (and how) it writes EFLAGS. Intel's instruction set reference manual has a Flags Affected section in the entry for every instruction. For some it's just None.
http://ref.x86asm.net/coder32.html has a handy table of instructions including a column showing which flags they read and modify, and which of the modified flags are well-defined vs. undefined. (Click on the column headers for a description).
Most integer ALU instructions, like sub and add, update FLAGS "according to the result"; this is where common descriptions like setting SF = high bit apply. Instructions like cmp and test only produce a FLAGS result, not modifying either integer input.
lea and not are notable ALU exceptions that don't set flags. Data-movement instructions don't set FLAGS, like mov and push/pop. e.g. Flags Affected: None.
inc/dec set flags except for CF, which they leave unmodified. (Most CPUs can still handle this efficiently)
SSE and fp instructions like addsd xmm, xmm/mem don't normally write flags. You can do FP compares into EFLAGS on modern x86 with comisd xmm, xmm/mem (SSE2) or fcomi st? (x87 + Pentium Pro).
Some examples from Intel's vol.2 manual:
Instructions that write flags in "interesting" ways often also define this in their "operation" section pseudocode. e.g. bsf
add: Flags Affected
The OF, SF, ZF, AF, CF, and PF flags are set according to the result.
(If you look at the PDF for Intel's vol.2 manual, or maybe vol.1, I think they define exactly what "according to the result" means. See What does "set according to the result" mean in Intel's SDM manuals? for a quote from vol.1 which gives the normal meanings for each flag.)
imul: Flags Affected:
For the one operand form of the instruction, the CF and OF flags are set when significant bits are carried into the upper half of the result and cleared when the result fits exactly in the lower half of the result. For the two- and three-operand forms of the instruction, the CF and OF flags are set when the result must be truncated to fit in the destination operand size and cleared when the result fits exactly in the destination operand size. The SF, ZF, AF, and PF flags are undefined.
sar / shl / shr Flags Affected:
The CF flag contains the value of the last bit shifted out of the destination operand; it is undefined for SHL and SHR instructions where the count is greater than or equal to the size (in bits) of the destination operand. The OF flag is affected only for 1-bit shifts (see “Description” above); otherwise, it is undefined. The SF, ZF, and PF flags are set according to the result. If the count is 0, the flags are not affected. For a non-zero count, the AF flag is undefined.
Leaving flags unmodified for count=0 is another crazy-CISC pothole for high-performance implementations to deal with. (Part of the "x86 tax" that a microarchitecture has to pay to implement x86 semantics correctly). On Intel Sandybridge-family, it means variable-count shifts (with count in cl) decode to 3 uops. SHLX (BMI2 no-flags shifts) are just 1 uop.
Another way to answer the "how often" question: up to 4 times per clock cycle. Or 5 on Zen or Ice Lake. (At most once per instruction.)
Modern Intel CPUs are 4-wide superscalar. They can rename EFLAGS 4 times in the same clock cycle, allowing them to run 4 independent add reg,reg instructions per clock cycle, each one writing its flag result to the logical EFLAGS register, but really a different physical register. (And actually piggybacking the EFLAGS output on the physical register holding the integer result, except instructions like cmp that don't have an integer result. So each uop only has to write one physical register. Instructions with more outputs decode to multiple uops on Intel at least, such as one-operand mul.)
